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DATA WAREHOUSING INFRASTRUCTURE 
FOR WEB BASED REPORTING TOOL 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

The following patent application is based on and claims 
the benefit of U.S. Provisional Patent Application Serial No. 
60/060,655, filed Sep. 26, 1997. This application is also 
related to the following applications which were all filed on 
Sep. 24, 1998. The related applications are U.S. application 
Ser. No. 09/159,695 (allowed); U.S. application Ser. No. 
09/159,515 (issued Sep. 5, 2000 as U.S. Pat. No. 6,115,040); 
U.S. application Ser. No. 09/159,512; U.S. application Ser. 
No. 09/159,408; U.S. application Ser. No. 09/159,514; U.S. 
application Ser. No. 09/159,684; U.S. application Ser. No. 
09/159,516; and U.S. application Ser. No. 09/159,409. 

FIELD OF THE INVENTION 

The present invention relates generally to information 
delivery systems and, particularly, to a novel, World Wide 
Web/Internet-based, telecommunications network data man- 
agement reporting and presentation service for customers of 
telecommunications service entities. 

BACKGROUND OF THE INVENTION 

Telecommunications service entities, e.g., MCI, AT&T, 
Sprint, and the like, presently provide for the presentation 
and dissemination of customer account and network data 
management information to their customers predominantly 
by enabling customers (clients) to directly dial-up, e.g., via 
a modem, to the entity's application servers to access their 
account information, or, alternately, via dedicated commu- 
nication lines, e.g., ISDN, T-l, etc., enabling account infor- 
mation requests to be initiated through their computer ter- 
minal running, for example, a Windows®-based graphical 
user interface. The requests are processed by the entity's 
application servers, which retrieves the requested customer 
information, e.g., from one or more databases, processes and 
formats the information for downloading to the client's 
computer terminal. 

Some types of data, e.g., "priced" call detail data pertain- 
ing to a customer's telecommunications number usage, is 
made available for customers in an aggregated or processed 
form and provided to customers, e.g., on a monthly basis. 
This type of data is analyzed to determine, for example, asset 
usage and trend information necessary, which is required for 
network managers to make critical business decisions. As an 
example, the assignee telecommunications carrier MCI Cor- 
poration provides an MCI Service View ("MSV") product 
line for its business customers which includes several client- 
server based data management applications. One of these 
applications, referred to as "Perspective," provides call 
usage and analysis information that focuses on the presen- 
tation of and priced call detail data and reports from an MCI 
Perspective Host Server ("PHost"). Another client-server 
based data management application, referred to as "Traffic 
View," focuses on the presentation of real time call detail 
data and network traffic analysis/monitor information as 
provided from an MCI Traffic view server. Particularly, with 
respect to MCI's Perspective system, customers are pro- 
vided with their monthly priced and discounted raw call 
detail data, call detail aggregates, and statistical historical 
summary data. As such, the Perspective architecture is 
organized primarily as a batch midrange -based server data 
delivery mechanism with the data being typically delivered 
on a monthly basis, allowing for "delayed" trending, call 
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pattern analysis, repricing and invoice validation based on 
the customer's call detail data. The trending, analysis, and 
repricing functionality is maintained in workstation-based 
software provided to customers for installation at customer 

5 sites on their PCS. 

FIG. 1 illustrates the current architecture 10 for Perspec- 
tive and Traffic View Systems which presently run on 
separate environments and are maintained independently of 
each other. The StarPR server provides a batch reporting 

10 mechanism focused primarily on providing billing data to 
l-800/8xx, VNET, Vision, and other MCI customers and is 
used by MCI customers predominantly to do internal charge 
backs and to analyze billing usage. Alternately, or in 
addition, the customers use the data provided to them to do 

15 call traffic analysis, similar to TVS. 

With specific reference to FIG. 1, the data collected is in 
the form of call detail records which are created by various 
MCI/Concert switches (not shown) whenever a telephone 
call is attempted in the MCI network and which includes 

20 information about call type, call origination and termination 
locations, date and time, added intelligent network services, 
any hop information, product type and other relevant infor- 
mation about the call. The Network Information Concentra- 
tor ("NIC") component 15 is a network element that collects 

25 the CDRs and sends them to appropriate locations via a 
Global Statistical Engine 17. The Global Statistical Engine 
17 collects the CDRs and transforms, processes, and sends 
them to the TVS 20. The TVS provides access to this data 
through various statistical reports and real time monitoring 

30 engine 22 ("RTM"). 

The CDRs are also sent to the billing system which 
applied billing based on call detail values. These "priced" 
CDRs are known as Billing Detail Records ("BDRs") and 

35 are sent to a Perspective Host("Phost" ) server 25. The Phost 
server 25 filters out the BDRs not pertaining to the "Per- 
spective" customers, applies various transformations to the 
customer's raw call detail data to generate summary data, 
and generates and formats the data for the various Perspec- 

40 tive customers. This data is then compressed, sent to a 
document service center ("DSC") and CD-ROM dispatcher 
("CDD") 34 entities which respectively, uncompresses the 
data and burns CD-ROMs comprising the customer's raw 
call detail data and summary data, in addition to reference 

45 files and possibly application software (if not previously 
owned) enabling customers to perform analysis and trending 
of their Perspective data. These CD-ROMs are sent to the 
customers, usually on a billing cycle or monthly basis, who 
view their data through a Perspective workstation-based 

5Q software application residing on that customer's CPE, e.g., 
PC or workstation 36. 

As shown in FIG. 1, the existing Perspective Host 25 
mainframe-based data delivery system interfaces with all 
Perspective upstream feed systems, including billing sys- 

55 , tems and order entry, and processes the data, e.g., creates 
canned aggregates, for delivery to the document service 
center. 

The following upstream feed systems include: 1) order 
entry information from a customer order entry system 19 

60 ("CORE") and which information is used by the Perspective 
Host to determine what customer data to process and where 
to send it; 2) VNET and Vision monthly billing data feeds 
from a commercial billing system ("NBCS") system 23; 3) 
a Tollfree monthly billing data feed from a T/F database feed 

65. 27; and, a Concert Virtual Network Services ("CVNS") 
product feed from a CVNS database 31. In order for all the 
CDR and data feed information to be processed by the Phost 
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server 25, various reference files and processing rules are detail data; a device for receiving customer's raw telecom- 
provided including: alphanumeric translation reference files munications call detail data records from one or more 
from the NCBS billing system 23 and an NPA/NXX-state- telecommunications network switch mechanisms, and 
city and country code lookup reference file originating from extracting certain call detail records for predetermined cus- 
a calling area data base ("CADB") 35. 5 tomers; a harvest device for receiving the extracted call 

While effective for its purpose, the current data manage- detaiJ data records and replacing a call detail data item 
ment and data storage legacy platform infrastructure only therein with a corresponding dimension key found in an 
provides customers with their priced call detail data on a associated dimension build table for that call detail item; 
monthly basis, usually in the form of a canned report. This an d, a device for generating an output fact table comprising 
is cot sufficient for an increasing number of customers who, 10 customer records having the unique key. structures for 
to remain competitive, are required to have updated daily enabling consolidated storage of specific customer call detail 
access to their data to enable them to make their critical da t*; at least one secure server for managing cheat sessions 
business decisions quicker. Moreover, these legacy plat- ove r the Internet, the secure server supporting secure corn- 
forms including reporting data are reaching the architectural munication of customer request messages between the 
limits of scalability in terms of the total customers they can 15 browser application client and the secure server; and, a 
support, total online data they can present, total historical device for receiving the customer requests from the secure 
data they can keep and type and number of applications they server and generating corresponding database queries imple- 
can support. menting the dimension keys for application against the 

Thus, a data warehousing approach that would support the output fact table to obtain a specific call customer's call 

daily processing and storage of customer's priced call detail 20 ^til data > the Recessed call detail data being transmitted 

data in a form suitable for expedient access and presentation ba u ck * <j heDt w f b 5 0W f r ™ the secure server; 

as a report for customers over the World Wide Web/Internet whe ' eb y expedient and updated web/Internet-based access 

would be highly desirable. to me s ^ detai1 data 15 assured - 

Advantageously, the data warehousing infrastructure for 

SUMMARY OF THE INVENTION 25 the Web/Internet based reporting system provides 

. . 4 . . 4 . j4 incremental, daily updates to data and allows users to report 

The present invention is a telecommunications data ... . \. 3 r ... , . u a 

r w 4 A . t . . i . on either daily or monthly data. BDR s may be processed 

management/system architecture integrated with a novel . , , , . ; . . / , . . J * frU1 

Web/Internet based reporting system Referred to as net- * nd d , ata mar * °° a ba f • °° a 

i xm^i i * ./„ * tr ^ i * *»»\ *i_ j * 1. 1 basis this daily data is replaced with records produced in the 

workMCI Interact ( nMQ Interact ), the data management/ , n ^-n- i nm. i 

v . . , ' , & , JU monthly billing run, after an audit approval. The goal of this 

system architecture implements a data warehouse approach , 3 *• • » i j i • j j *u 

/ . . . . , . , L . , c . ..... rr . replace operation is to replace daily priced records with the 

to maintaining data obtained from upstream billing systems, *; . r , , 4 r A ' r lL1 . 

• j ii j * i j * j u • u j . , . actual records used to compute monthly billing. Inis is 

i.e.. priced call detail data, and which data may be made , . r - *, , , 

\.i -i ui r »• j -i u * i *u* necessary because a large percentage of the daily records, 

readily available for reporting on a daily basis. In this . , 3 , .. , . *\ f .~ & , . , *\ , 

J , . , .. . j *i i - • * * • j • j* pneed on a daily basis at tariff, may be repriced based on 

approach, priced call detail data is maintained in data marts, « r it _. ,. * „ Al _ , , f\ , , 

rr i j * a ui c *• i *■ monthly discounts. Additionally, monthly data may also be 

i.e., operational data stores, capable ot meeting real-time , A i . , _. 4 J '. J . 

r . • i i *u j a updated based on audit anomalies. The monthly replace 

processing and storage requirements. Particularly, these data r 4 . 4| _ r , , ^ , 

r ^ & , ,.f. j , , . J . . operation thus ensures the accuracy of the data used by 

marts may be partitioned based on various criteria, e.g., , 3 J 

, . ° customers 
customer id, to enable easier management of data by pro- 
viding scalability, and enabling more control of over hard- ^ Furthermore, the data management system permits use of 
ware and software resources, in a cost-effective way. existing hardware while allowing future growth to utilize 
Additionally, this data mart approach may implement a new equipment at less cost and further, allows for mere- 
back-end server component that receives data access mental expansion as applications and database capacities 
requests from various users in the form of a report request, grow, 
interactive data analysis request or data mining request. This 45 
server routes the query to the appropriate data marts, data 
warehouse or operational data store and responds to the Further features and advantages of the invention will 
requestor with the result set. become more readily apparent from a consideration of the 
The nMCI Interact Reporting system and data warehous- following detailed description set forth with reference to the 
ing infrastructure is a layer functioning to enable customers 50 accompanying drawings, which specify and show preferred 
to request reporting functionality across the Web/Internet. embodiments of the invention, wherein like elements are 
This report request functionality includes routing requests to designated by identical references throughout the drawings; 
appropriate data marts, e.g., real-time reporting requests and in which: 

may be satisfied by real-time database. Additionally, the pjrj 1 illustrates conceptually an existing mainframe- 
interface provides customers with the ability to schedule and 55 5^ data delivery system 10 providing customer's call 
prioritize reports, format report request result sets, and detail data* 

provides for load balancing report request validation, query FIG. 2 illustrates the software architecture component 

generation and execution. Through a common GUI, custom- * • *i_ *• j * 

& . , A t .u ■ u-ii* if i *i j * comprising a three-tiered structure; 

ers are enabled to access their own billing call detail data. 

T , . A , iL . . . - A , lt _ FIG. 3 is a diagrammatic overview of the software archi- 

In accordance with the principles or the invention, there 60 ^ ^ - . ft r . 

•j j w l/t * 5i_ j t - * c tecture of the networkMCI Interact system; 

is provided a Web/Internet based reporting system for pro- 3 9 

viding timely delivery of a customer's priced telecommu- FIG - 4 * an illustrative example of a backplane architec- 

nications call detail data to a client workstation running a schematic; 

veb browser application, the system comprising: a data FIG. 5 illustrates an example client GUI presented to the 

warehousing infrastructure including: a process, for gener- 65 client/customer as a browser web page; 

ating a current customer list on a daily basis comprising FIG. 6 is a diagram depicting the physical networkMCI 

customers entitled to receive daily telecommunications call Interact system architecture; 
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FIG. 7 illustrates the primary data warehousing compo- 
nents implemented in the StarODS priced reporting com- 
ponent 400; 

FIG. 8 illustrates the StarODS data extract process 500; 

FIG. 9 illustrates the data model implemented for access- 5 
ing information used in priced reporting system of nMCI 
Interact; 

FIG. 10 depicts generally the creation of the BDR record 
fact table during the harvest process; Q 

FIG. 11 illustrates the StarODS data harvest process 600; 

FIG. 12 is a block diagram depicting the physical archi- 
tecture of the StarWRS component of networkMCI Interact 
Reporting system; 

FIG. 13(a) illustrates the logical Report Manager/DSS 15 
application programming interface; 

FIG. 13(b) illustrates the logical DSS/Report Manager 
application programming interface; 

FIGS. 14(a)-14(&) illustrate an overview of the process 2Q 
performed by the DSS in routing a request; 

FIG. 15(a) illustrates an overview of the DSS connections 
enabling guaranteed message delivery in the nMCI Interact 
System; 

FIG. 15(6) illustrates the formatter process implemented 25 
in the DSS server; 

FIGS. 16(a)-16(c) illustrate the end-to-end process 800 
for fulfilling priced report request; 

FIG. 17 illustrates a logical message format sent from the 
client browser to the desired middle tier server for a par- 30 
ticular application; and 

FIGS. 18(a) and 18(fc) are schematic illustrations showing 
the message format passed between the Dispatcher server 
and the application specific proxy (FIG. 18(a)) and the 3S 
message format passed between the application specific 
proxy back to the Dispatcher server (FIG. 18(b)). 

DETAILED DESCRIPTION OF THE 
INVENTION 

40 

The present invention is one component of an integrated 
suite of customer network management and report applica- 
tions using a Web browser paradigm. Known as the net- 
workMCI Interact system ("nMCI Interact") such an inte- 
grated suite of Web-based applications provides an 45 
invaluable tool for enabling customers to manage their 
telecommunication assets, quickly and securely, from any- 
where in the world. 

As described in co-pending U.S. patent application Ser. 
No. 09/159,695, filed Sep. 24, 1998 (D#11038), the nMCI 50 
Interact system architecture is basically organized as a set of 
common components comprising the following: 

1) an object-oriented software architecture detailing the 
client and server based aspect of nMCI Interact; 5J 

2) a network architecture defining the physical network 
needed to satisfy the security and data volume require- 
ments of the networkMCI System; 

3) a data architecture detailing the application, back-end 

or legacy, data sources available for networkMCI Inter- 60 
act; and 

4) an infrastructure covering security, order entry, 
fulfillment, billing, self-monitoring, metrics and sup- 
port 

Each of these common component areas will be generally 65 
discussed hereinbelow. A detailed description of each of 
these components can be found in a related, co-pending U.S. 
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patent application Ser. No. 09/159,695, filed Sep. 24, 1998 
entided INTEGRATED CUSTOMER INTERFACE SYS- 
TEM FOR COMMUNICATIONS NETWORK 
MANAGEMENT, the disclosure of which is incorporated 
herein by reference thereto. 

FIG. 2 is a diagrammatic illustration of the software 
architecture component in which the present invention func- 
tions. A first or client tier 40 of software services are resident 
on a customer work station and provides customer access to 
the enterprise system, having one or more downloadable 
application objects directed to front end business logic, one 
or more backplane service objects for managing sessions, 
one or more presentation services objects for the presenta- 
tion of customer options and customer requested data in a 
browser recognizable format and a customer supplied 
browser for presentation of customer options and data to the 
customer and for Internet communications over the public 
Internet. Additionally applications are directed to front end 
services such as the presentation of data in the form of tables 
and charts, and data processing functions such as sorting and 
summarizing in a manner such that multiple programs are 
combined in a unified application suite. A second or middle 
tier 42, is provided having secure web servers and back end 
services to provide applications that establish user sessions, 
govern user authentication and their entitlements, and com- 
municate with adaptor programs to simplify the interchange 
of data across the network. 

A third or back end tier 45 having applications directed to 
legacy back end services including database storage and 
retrieval systems and one or more database servers for 
accessing system resources from one or more legacy hosts. 

Generally, as explained in commonly owned, co-pending 
U.S. patent application Ser. No. 09/159,515, filed Sep. 24, 
1998 (issued as U.S. Pat. No. 6,115,040 on Sep. 5, 2000), 
entitled GRAPHICAL USER INTERFACE FOR WEB 
ENABLED APPLICATIONS, the disclosure of which is 
incorporated herein by reference thereto, the customer work- 
station includes client software capable of providing a 
platform-independent, browser-based, consistent user inter- 
face implementing objects programmed to provide a reus- 
able and common GUI abstraction and problem-domain 
abstractions. More specifically, the clienttier software is 
created and distributed as a set of Java classes including the 
applet classes to provide an industrial strength, object- 
oriented environment over the Internet. Application-specific 
classes are designed to support the functionality and server 
interfaces for each application with the functionality deliv- 
ered through the system being of two-types: 1) cross- 
product, for example, inbox and reporting functions, and 2) 
product specific, for example, toll free network management 
or Call Manager functions. The system is capable of deliv- 
ering to customers the functionality appropriate to their 
product mix. 

FIG. 3 is a diagrammatic overview of the software archi- 
tecture of the networkMCI Interact system including: the 
Customer Browser (a.k.a. the Client) 50; the Demilitarized 
Zone (DMZ) 47 comprising a Web Servers cluster 44; the 
MCI Intranet Dispatcher Server 46; and the MCI Intranet 
Application servers 60, and the data warehouses, legacy 
systems, etc. 80. 

A customer workstation 51 employs a Web Browser 50 
implementing client applications responsible for presenta- 
tion and front-end services. Its functions include providing 
a user interface to various MCI services and supporting 
communications with MCI's Intranet web server cluster 44. 
As illustrated in FIG. 3, and more specifically described in 
the above-mentioned, co-pending U.S. patent application 
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Ser. No. 09/159,515, filed Sep. 24, 1998 (issued as U.S. Pat. The backplane architecture is implemented with several 

No. 6,115,040 on Sep. 5, 2000) entitled GRAPHICAL primary classes. These classes include COBackPlane, 

USER INTERFACE FOR WEB ENABLED CO App, CO Applmpl, COParm, and COAppFrame classes. 

APPLICATIONS, the client tier software is responsible for COBackPlane 52 is an application backplane which 

presentation services to the customer and generally includes 5 launches the applications 54a, 54/?, typically implemented as 

a web browser 50 and additional object-oriented programs COApp. COBackPlane 52 is generally implemented as a 

residing in the client workstation platform 51. The client Java applet and is launched by the Web browser 50. This 

software is generally organized into a component architec- backplane applet is responsible for launching and closing the 

ture with each component generally comprising a specific COApps. 

application, providing an area of functionality. The applica- 10 When the backplane is implemented as an applet, it 

tions generally are integrated using a "backplane" services overrides standard Applet methods init( ), start( ), stop( ) and 

layer 52 which provides a set of services to the application run( ). In the init( ) method, the backplane applet obtains a 

objects which provide the front end business logic and COUser user context object. The COUser object holds 

manages their launch. The networkMCI Interact common information such as user profile, applications and their 

set of objects provide a set of services to each of the 15 entitlements. The user's configuration and application 

applications such as; 1) session management; 2) application entitlements provided in the COUser context are used to 

launch; 3) inter-application communications; 4) window construct the application toolbar and Inbox applications, 

navigation among applications; 5) log management; and 6) When an application toolbar icon is clicked, a particular 

version management. COApp is launched by launchApp( ) method. The launched 

The primary common object services include: graphical 20 application then may use the backplane for inter-application 

user interface (GUI); communications; printing; user communications, including retrieving Inbox data, 

identity, authentication, and entitlements; data import and The COBackPlane 52 includes methods for providing a 

export; logging and statistics; error handling; and messaging reference to a particular COApp, for interoperation. For 

services. example, the COBackPlane class provides a getApp( ) 

FIG. 4 is a diagrammatic example of a backplane archi- 25 method which returns references to application objects by 

tecture scheme illustrating the relationship among the com- name. Once retrieved in this manner, the application object's 

mon objects. In this example, the backplane services layer public interface may be used directly. 

52 is programmed as a Java applet which can be loaded and The use of a set of common objects for implementing the 

launched by the web browser 50. With reference to FIG. 4, various functions provided by the system of the present 

a typical user session starts with a web browser 50 creating 30 invention, and particularly the use of browser based objects 

a backplane 52, after a successful logon. The backplane 52, to launch applications and pass data therebetween is more 

inter alia, presents a user with an interface for networkMCI fully described in the above -referenced, copending applica- 

Interact application management. A typical user display tion GRAPHICAL USER INTERFACE FOR WEB 

provided by the baclqjlane 52 may show a number of ENABLED APPLICATIONS. 

applications the user is entitled to run, each application 35 As shown in FIG. 3, the aforesaid objects will commu- 

represented by buttons depicted in FIG. 4 as buttons SSa,b,c nicate the data by establishing a secure TCP messaging 

selectable by the user. As illustrated in FIG. 4, upon selec- session with one of the DMZ networkMCI Interact Web 

tion of an application, the backplane 52 launches that servers 44 via an Internet secure communications path 32 

specific application, for example, Service Inquiry 54a or established, preferably, with a secure sockets SSL version of 

Alarm Monitor 54b, by creating the application object. In 40 HTTPS. The DMZ networkMCI Interact Web servers 44 

processing its functions, each application in turn, may utilize function to decrypt the client message, preferably via the 

common object services provided by the backplane 52. FIG. SSL implementation, and unwrap the session key and verify 

4 shows graphical user interface objects 56a, b created and the users session. After establishing that the request has 

used by a respective application 54a, b for its own presen- come from a valid user and mapping the request to its 

tation purposes. 45 associated session, the DMZ Web servers 44 will re-encrypt 

FIG. 5 illustrates an example client GUI presented to the the request using symmetric encryption and forward it over 

client/customer as a browser web page 71 providing, for a second socket connection 33 to the dispatch server 46 

example, a suite 70 of network management reporting inside the enterprise Intranet. 

applications including: MCI Traffic Monitor 72; an alarm As described in greater detail in commonly owned, 

monitor 73; a Network Manager 74 and Intelligent Routing 50 co-pending U.S. patent application Ser. No. 09/159,514, 

75. Access to network functionality is also provided through filed Sep. 24, 1998 entitled SECURE CUSTOMER INTER- 

Report Requester 76, which provides a variety of detailed FACE FOR WEB-BASED DATA MANAGEMENT, the 

reports for the client/customer and a Message Center 77 for contents and disclosure of which is incorporated by refer- 

providing enhancements and functionality to traditional ence as if fully set forth herein, a networkMCI Interact 

e-mail communications. 55 session is designated by a logon, successful authentication, 

As shown in FIGS. 3 and 4, the browser resident GUI of followed by use of server resources, and logoff. However, 

the present invention implements a single object, COBack- the world-wide web communications protocol uses HTTP, a 

Plane which keeps track of all the client applications, and stateless protocol, each HTTP request and reply is a separate 

which has capabilities to start, stop, and provide references TCP/IP connection, completely independent of all previous 

to any one of the client applications. 60 or future connections between the same server and client. 

The backplane 52 and the client applications use a The nMCI Interact system is implemented with a secure 

browser 50 such as the Microsoft Explorer versions 4.0.1 or version of HTTP such as S-HTTP or HTTPS, and preferably 

higher for an access and distribution mechanism. Although utilizes the SSL implementation of HTTPS. The preferred 

the backplane is initiated with a browser 14, the client embodiment uses SSL which provides a cipher spec message 

applications are generally isolated from the browser in that 65 which provides server authentication during a session. The 

they typically present their user interfaces in a separate preferred embodiment further associates a given HTTPS 

frame, rather than sitting inside a Web page. request with a Logical session which is initiated and tracked 
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by a "cookie jar server" 48 to generate a "cookie" which is. As partially shown in FIG. 3, it is understood that each 
a unique server-generated key that is sent to the client along Intranet server of suite 60 communicates with one or several 
with each reply to a HTTPS request. The client holds the consolidated network databases which include each custom- 
cookie and returns it to the server as part of each subsequent er's network management information and data. In the 
HTTPS request. As desired, either the Web servers 44, the 5 present invention the Services Inquiry server 36 includes 
cookie jar server 48 or the Dispatch Server 46, may maintain communication with MO's Customer Service Management 
the "cookie jar" to map these keys to the associated session. legacy platform 80(a). Such network management and cus- 
A separate cookie jar server 48, as illustrated in FIG. 3 has tomer network data is additionally accessible by authorized 
been found desirable to minimize the load on the dispatch MCI management personnel. As shown in FIG. 3, other 
server 46. This form of session management also functions 10 legacy platforms 80(6), 80(c) and 80(d) may also commu- 
as an authentication of each HTTPS request, adding an nicate individually with the Intranet servers for servicing 
additional level of security to the overall process. specific transactions initiated at the client browser. The 

As illustrated in FIG. 3, after one of the DMZ Web servers illustrated legacy platforms 80(a}-(d) are illustrative only 
44 decrypts and verifies the user session, it forwards the and it is understood other legacy platforms may be inter- 
message through a firewall 55b over a TCP/IP connection 33 is preted into the network architecture illustrated in FIG. 3 
to the dispatch server 46 on a new TCP socket while the through an intermediate midrange server 60. 
original socket 32 from the browser is blocking, waiting for Each of the individual proxies may be maintained on the 
a response. The dispatch server 46 will unwrap an outer dispatch server 46, the related application server, or a 
protocol layer of the message from the DMZ services cluster separate proxy server situated between the dispatch server 
44, and will reencrypt the message with symmetric encryp- 20 46 and the midrange server 30. The relevant proxy waits for 
tion and forward the message to an appropriate application requests from an application client running on the custom - 
proxy via a third TCP/IP socket 37. While waiting for the er's workstation 50 and then services the request, either by 
proxy response, all three of the sockets 32, 33, 37 will be handling them internally or forwarding them to its associ- 
blocking on a receive. Specifically, once the message is ated Intranet application server 60. The proxies additionally 
decrypted, the wrappers are examined to reveal the user and 25 receive appropriate responses back from an Intranet appli- 
the target middle-tier (Intranet application) service for the cation server 60. Any data returned from the Intranet appli- 
request. A first-level validation is performed, making sure cation server 60 is translated back to client format, and 
that the user is entitled to communicate with the desired returned over the Internet to the client workstation 50 via the 
service. The user's entitlements in this regard are fetched by Dispatch Server 46 and at one of the web servers in the DMZ 
the dispatch server 46 from StarOE server 69 at logon time 30 Services cluster 44 and a secure sockets connection. When 
and cached. the resultant response header and trailing application spe- 

If the requester is authorized to communicate with the cific data are sent back to the client browser from the proxy, 

target service, the message is forwarded to the desired the messages will cascade all the way back to the browser 14 

service's proxy. Each application proxy is an application in real time, limited only by the transmission latency speed 

specific daemon which resides on a specific Intranet server, 35 of the network. 

shown in FIG. 3 as a suite of mid -range servers 60. Each The networkMCI Interact middle tier software includes a 

Intranet application server of suite 60 is generally respon- communications component offering three (3) types of data 

sible for providing a specific back-end service requested by transport mechanisms: 1) Synchronous; 2) Asynchronous; 

the client, and, is additionally capable of requesting services and 3) Bulk transfer. Synchronous transaction is used for 

from other Intranet application servers by communicating to 40 situations in which data will be returned by the application 

the specific proxy associated with that other application server 60 quickly. Thus, a single TCP connection will be 

server. Thus, an application server not only can offer its made and kept open until the full response has been 

browser a client to server interface through the proxy, but retrieved. 

also may offer all its services from its proxy to other Asynchronous transaction is supported generally for situ- 

application servers. In effect, the application servers request- 45 ations in which there may be a long delay in application 

ing service are acting as clients to the application servers server 60 response. Specifically, a proxy will accept a 

providing the service. Such mechanism increases the secu- request from a customer or client 50 via an SSL connection 

rity of the overall system as well as reducing the number of and then respond to the client 50 with a unique identifier and 

interfaces. close the socket connection. The client 50 may then poll 

The network architecture of FIG. 3 may also include a so repeatedly on a periodic basis until the response is ready, 

variety of application specific proxies having associated Each poll will occur on a new socket connection to the 

Intranet application servers including: a StarOE proxy for proxy, and the proxy will either respond with the resultant 

the StarOE application server 69 for handling authentication data or, respond that the request is still in progress. This will 

order entry/billing; an Inbox proxy for the Inbox application reduce the number of resource consuming TCP connections 

server 61, which functions as a container for completed 55 open at any time and permit a user to close their browser or 

reports, call detail data and marketing news messages, a disconnect a modem and return later to check for results. 

Report Manager Proxy capable of communicating with a Bulk transfer is generally intended for large data transfers 

system-specific Report Manager server 62 for generating, and are unlimited in size. Bulk transfer permits cancellation 

managing and scheduling the transmission of customized during a transfer and allows the programmer to code 

reports including, for example: call usage analysis informa- 60 resumption of a transfer at a later point in time, 

tion provided from the StarODS server 63; network traffic FIG. 6 is a diagram depicting the physical networkMCI 

analysis/monitor information provided from the Traffic view Interact system architecture 100. As shown in FIG. 6, the 

server 64; virtual data network alarms and performance system is divided into three major architectural divisions 

reports provided by Broadband server 65; trouble tickets for including: 1) the customer workstation 50 which include 

switching, transmission and traffic faults provided by Ser- 65 those mechanisms enabling customer connection to the 

vice Inquiry server 66; and toll free routing information Secure web servers 44; 2) a secure network area 47, known 

provided by Toll Free Network Manager server 67. as the DeMilitarized Zone "DMZ" set aside on MCI pre- 
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mises double firewalled between the both the public Internet 

85 and the MCI Intranet to prevent potentially hostile 
customer attacks; and, 3) the MCI Intranet Midrange Servers 
60 and Legacy Mainframe Systems 80 which comprise the 
back end business logic applications. 

As illustrated in FIG. 6, the present invention includes a 
double or complex firewall system that creates a "demilita- 
rized zone" (DMZ) between two firewalls 55a, 55b. In the 
preferred embodiment, one of the firewalls 55b includes port 
specific filtering routers, which may only connect with a 
designated port address. For example, router 84 (firewall 
55(a)) may connect only to the addresses set for the 
Hydra Web® (or web servers 44) within the DMZ, and router 

86 (firewall 55(6)) may only connect to the port addresses 
set for the dispatch server 46 within the network. In addition, 
the dispatch server 46 connects with an authentication 
server, and through a proxy firewall to the application 
servers. This ensures that even if a remote user ID and 
password are hijacked, the only access granted is to one of 
the web servers 44 or to intermediate data and privileges 
authorized for that user. Further, the hijacker may not 
directly connect to any enterprise server in the enterprise 
Intranet beyond the DMZ, thus ensuring internal company 
system security and integrity. Even with a stolen password, 
the hijacker may not connect to other ports, root directories 
or application servers within the enterprise system, and the 
only servers that may be sabotaged or controlled by a hacker 
are the web servers 44. 

The DMZ 47 acts as a double firewall for the enterprise 
Intranet because of the double layer of port specific filtering 
rules. Further, the web servers 44 located in the DMZ never 
store or compute actual customer sensitive data. The web 
servers only transmit the data in a form suitable for display 
by the customer's web browser. Since the DMZ web servers 
do not store customer data, there is a much smaller chance 
of any customer information being jeopardized in case of a 
security breach. In the preferred embodiment, firewalls or 
routers 84,86 are a combination of circuit gateways and 
filtering gateways or routers using packet filtering rules to 
grant or deny access from a source address to a destination 
address. All connections from the internal application serv- 
ers are proxied and filtered through the dispatcher before 
reaching the web servers 44. Thus it appears to any remote 
site, that the connection is really with the DMZ site, and 
identity of the internal server is doubly obscured. This also 
prevents and direct connection between any external and any 
internal network or intranet computer. 

The filtering firewalls 55(a),(6) may also pass or block 
specific types of Internet protocols. For example, FTP can be 
enabled only for connections to the In-Box server 61, and 
denied for all other destinations. SMTP can also be enabled 
to the In-Box server, but Telnet denied. The In-box server 61 
is a store and forward server for client designated reports, 
but even in this server, the data and meta-data are separated 
to further secure the data, as will be described. 

As previously described, the customer access mechanism 
is a client workstation 51 employing a Web browser 50 for 
providing the access to the networkMCI Interact system via 
the public Internet 85. When a subscriber connects to the 
networkMCI Interact Web site by entering the appropriate 
URL, a secure TCP/IP communications link 32a is estab- 
lished to one of several Web servers 44 located inside a first 
firewall 55a in the DMZ 47. Preferably at least two web 
servers are provided for redundancy and failover capability. 
In the preferred embodiment of the invention, the system 
employs SSL encryption so that communications in both 
directions between the subscriber and the networkMCI 
Interact system are secure. 
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In the preferred embodiment, all DMZ Secure Web serv- 
ers 44 are preferably DEC 4100 systems having Unix or 
NT-based operating systems for running services such as 
HTTPS, FTP, and Telnet over TCP/IP. The web servers may 

5 be interconnected by a fast Ethernet LAN running at 100 
Mbit/sec or greater, preferably with the deployment of 
switches within the Ethernet LANs for improved bandwidth 
utilization. One such switching unit included as part of the 
network architecture is a HydraWEB® unit 82, manufac- 

10 tured by HydraWEB Technologies, Inc., which provides the 
DMZ with a virtual IP address so that subscriber HTTPS 
requests received over the Internet will always be received. 
The Hydraweb® unit 82 implements a load balancing algo- 
rithm enabling intelligent packet routing and providing 

15 optimal reliability and performance by guaranteeing acces- 
sibility to the "most available" server. It particularly moni- 
tors all aspects of web server health from CPU usage, to 
memory utilization, to available swap space so that Internet/ 
Intranet networks can increase their hit rate and reduce Web 

20 server management costs. In this manner, resource utiliza- 
tion is maximized and bandwidth (throughput) is improved. 
It should be understood that a redundant Hydraweb® unit 
may be implemented in a Hot/Standby configuration with 
heartbeat messaging between the two units (not shown). 

25 Moreover, the networkMCI Interact system architecture 
affords web server scaling, both in vertical and horizontal 
directions. Additionally, the architecture is such that new 
secure web servers 44 may be easily added as customer 
requirements and usage increases. 

30 As shown in FIG. 6, the most available Web server 44 
receives subscriber HTTPS requests, for example, from the 
HydraWEB® 82 over a connection 44b and generates the 
appropriate encrypted messages for routing the request to 
the appropriate MCI Intranet midrange web server over 

35 connection 44a, router 86 and connection 44b. Via the 
Hydraweb® unit 82, a TCP/IP connection 38 links the 
Secure Web server 44 with the MCI Intranet Dispatcher 
server 46. 

Further as shown in the DMZ 47 is a second RTM server 

40 92 having its own connection to the public Internet via a 
TCP/IP connection 88. As described in co-pending U.S. 
patent application Sen No. 09/159,516, filed Sep. 24, 1998 
entitled INTEGRATED PROXY INTERFACE FOR WEB 
BASED TELECOMMUNICATIONS MANAGEMENT 

45 TOOLS, this RTM server provides real-time session man- 
agement for subscribers of the networkMCI Interact Real 
Time Monitoring system. An additional TCP/IP connection 
88a links the RTM Web server 92 with the MCI Intranet 
Dispatcher server 46. As further shown in FIG. 6, a third 

50 router 87 is provided for routing encrypted subscriber mes- 
sages from the RTM Web server 92 to the Dispatcher server 
46 inside the second firewall. Although not shown, each of 
the routers 86, 87 may additionally route signals through a 
series of other routers before eventually being routed to the 

55 nMCI Interact Dispatcher server 46. In operation, each of 
the Secure servers 44 function to decrypt the client message, 
preferably via the SSL implementation, and unwrap the 
session key and verify the users session from the COUser 
object authenticated at Logon. 

60 After establishing that the request has come from a valid 
user and mapping the request to its associated session, the 
Secure Web servers 44 will re-encrypt the request using 
symmetric RSA encryption and forward it over a second 
socket connection 38 to the dispatch server 46 inside the 

65 enterprise Intranet. 

As described herein, and in greater detail in co -pending 
U.S. patent application Ser. No. 09/159,695, filed Sep. 24, 
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1998 the data architecture component of the networkMCI 
Interact system is focused on the presentation of real time 
(un-priced) call detail data, such as provided by MCI's 
TrafficView Server 64, and priced call detail data and 
reports, such as provided by MCFs StarODS Server 63 in a 
variety of user selected formats. 

All reporting is provided through a Report Requestor GUI 
application interface which support spreadsheet, a variety of 
graph and chart types, or both simultaneously. For example, 
the spreadsheet presentation allows for sorting by any arbi- 
trary set of columns. The report viewer may also be launched 
from the inbox when a report is selected. 

A common database may be maintained to hold the 
common configuration data which can be used by the GUI 
applications and by the mid- range servers. Such common 
data will include but not be limited to: customer security 
profiles, billing hierarchies for each customer, general ref- 
erence data (states, NPA's, Country codes), and customer 
specific pick lists: e.g., ANTs, calling cards, etc. An MCI 
Internet StarOE server will manage the data base for the 
common configuration of data. 

Report management related data is also generated which 
includes 1) report profiles defining the types of reports that 
are available, fields for the reports, default sort options and 
customizations allowed; and 2) report requests defining 
customer specific report requests including report type, 
report name, scheduling criteria, and subtotal fields. This 
type of data will be resident in an Inbox server database and 
managed by the Inbox server. 

The Infrastructure component of the nMCI Reporting 
system includes means for providing secure communica- 
tions regardless of the data content being communicated. As 
described in detail in above-referenced, co-pending U.S. 
patent application Ser. No. 09/159,514, filed Sep. 24, 1998 
the nMCI Interact system security infrastructure includes: 1) 
authentication, including the use of passwords and digital 
certificates; 2) public key encryption, such as employed by 
a secure sockets layer (SSL) encryption protocol; 3) 
firewalls, such as described above with reference to the 
network architecture component; and 4) non-repudiation 
techniques to guarantee that a message originating from a 
source is the actual identified sender. One technique 
employed to combat repudiation includes use of an audit 
trail with electronically signed one-way message digests 
included with each transaction. 

Another component of the nMCI Interact infrastructure 
includes order entry, which is supported by the Order Entry 
("StarOE") server. The general categories of features to be 
ordered include: 1) Priced Reporting; 2) Real-time Report- 
ing; 3) Priced Call Detail; 4) Real Time Call Detail; 5) 
Broadband SNMP Alarming; 6) Broadband Reports; 7) 
Inbound RTM; 8) Outbound RTM; 9) Toll Free Network 
Manager; and 10) Call Manager. The order entry function- 
ality is extended to additionally support 11) Event Monitor; 
12) Service Inquiry; 13) Outbound Network Manager; 14) 
Portfolio; and, 15) Client View. 

The Self-monitoring infrastructure component for nMCI 
Interact is the employment of mid-range servers that support 
SNMP alerts at the hardware level. In addition, all software 
processes must generate alerts based on process health, 
connectivity, and availability of resources (e.g., disk usage, 
CPU utilization, database availability). 

The Metrics infrastructure component for nMCI Interact 
is the employment of means to monitor throughput and 
volumes at the Web servers, dispatcher server, application 
proxies and mid-range servers. Metrics monitoring helps in 
the determination of hardware and network growth. 
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To provide the areas of functionality described above, the 
client tier 50 is organized into a component architecture, 
with each component providing one of the areas of func- 
tionality. As explained in further detail in co-pending U.S. 

5 patent application Ser. No. 09/239,115, the client-tier soft- 
ware is organized into a "component" architecture support- 
ing such applications as inbox fetch and inbox management, 
report viewer and report requester, TFNM, Event Monitor, 
Broadband, Real-Time Monitor, and system administration 

10 applications. Further functionality integrated into the soft- 
ware architecture includes applications such as Outbound 
Network Manager, Call Manager, Service Inquiry and Client 
View. 

The present invention relates to a data warehousing 

IS infrastructure for the StarODS Priced call detail data report- 
ing component of the nMCI Interact system 200. The 
diagram of FIG. 7 illustrates, at a very high level, the 
systems involved in modifying and delivering BDRs to the 
StarODS priced call detail data reporting system, and in 

20 requesting, creating and delivering reports to the customer 
based upon those records. The systems and their functions 
are described in greater detail below. 

As shown in FIG. 7, the StarODS data management 
architecture, which is integrated with the StarWRS compo- 

25 nent of the nMCI Interact architecture, comprises a data 
warehousing infrastructure 400 for providing customers 
with their priced call detail data. Although the description 
herein pertains to priced data, it should be understood that 
the principles described herein could apply to any type of 

30 data, e.g., traffic call detail data. 

Preferably, the StarODS system provides reporting and 
customization of priced call detail data and implements a 
data marts approach for maintaining the data used for 
customer reporting. StarODS stores and incrementally pro- 

35 cesses customer's priced data contained in call detail 
records, and loads this processed data in operational data 
stores or data marts. From these data marts customer's 
priced reporting data are provided to customers on a daily 
basis via the StarWRS reporting system in the manner as 

40 described in co-pending U.S. patent application Ser. No. 
09/159,684, filed Sep. 24, 1998 entitled INTEGRATED 
PROXY INTERFACE FOR WEB-BASED DATA MAN- 
AGEMENT TOOL, the contents and disclosure of which is 
incorporated by reference as if fully set forth herein. 

45/*/ As shown in FIG. 7, the data warehousing infrastructure 
400 comprises the following system components: a traffic 
component 405 for receiving call detail records, sorting 
CDRs into billable records, error and suspense records, 
expands records, CustlD's, prices at tariff; 2) a National 

so Commercial Billing System "NCBS" mainframe process 
410 that performs pricing at tariff for nMCI Interact virtual 
network ("Vner") and Vision customers and, processes by 
runstream at one or more datacenters; 3) a Tollfree Billing 
mainframe process 420 that performs pricing at tariff for 

55 Tollfree customers and, processes by runstream at one or 
more datacenters; 4) Common Data Gateway (CDG) 430 
comprising: a) an Extract process 500 for creating selection 
tables including all current nMCI Interact customers, com- 
pressing files for transmission to service centers, and extract- 

60 ing (Priced Reporting enabled) records from divisions or 
runstreams; and, b) a Harvesting component 600 including 
prpcesses for creating dimension tables based on data within 
selected BDRs, applying business rules to the data, trans- 
forming the data into centralized fact table, creating load 

65 files for data marts, and compressing files for transmission; 
5) Operational Data Store (ODS) component 450, including 
a process 465 for loading transformed billing detail records 
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as a centralized fact table in one or more data marts storage 
devices, and integrating both static and dynamic dimension 
tables 460 according to a star-schema structure so that 
on-demand reports may be efficiently produced; 6) data 
marts 470 for storing the billing detail records in a fact table 
database, e.g., Informix, organized in a star-schema structure 
to facilitate priced call detail reporting; 7) a Decision 
Support Server 475 executing a combination of logic pro- 
grams such as C++ and Information Advantage® software 
for use as the reporting engine. This component reads 
metadata, translates into queries, runs queries against har- 
vested data fact tables in data marts, formats query results 
into a format readable by Message Center viewers, transmits 
complete reports to directory on Inbox server, and, 
additionally, performs cost estimation, scheduling, transac- 
tion logging and generates report metrics; and, 8) Talarian 
Smart Sockets interface between the decision support server 
and the StarWRS report requester reporting system com- 
prising messaging middleware used to coordinate report 
requests transmitted from StarWRS to DSS. 

Additionally, as shown in the FIG. 7, other external 
systems and applications may interface with the common 
data gateway component 430 including: Cyclone Billing 
system 422a and Concert Virtual Network Services 4226 
which provide additional billing detail records; and, a call- 
ing area database 425 which provides geographical refer- 
ence information, i.e., identify city, state and country infor- 
mation. 

Additionally shown in FIG. 7, and explained in greater 
detail in co-pending U.S. patent application Ser. No. 09/159, 
684, filed Sep. 24, 1998, is the StarWRS web based report- 
ing system 200 including: Report Manager for storing report 
definitions, metadata; Report requestor for providing the 
interface used by the customer to enter report criteria, and 
submit report metadata to Decision Support Server; and, 
StarWRS Inbox or Message Center for holding completed 
reports, providing an interface notifying customer that 
reports are available, and supplying metadata to a Report 
Viewer component so that user can view a report. 

As will be explained, the data warehousing process is a 
two fold approach including the provision of incremental, 
daily updates to the data marts for customer's priced billing 
data, and, a monthly audit/reconciliation to ensure that daily 
totals for priced data closely tracks monthly totals, within a 
predetermined variance, for the same data that may have 
been subject to re-pricing efforts. For example, daily priced 
call detail data totals, e.g., total call amount, duration and 
count, for a customer may match to within 5 percent 
variance, of their corresponding monthly data that is used for 
invoicing. 

FIG. 8 illustrates a detailed overview of the extracting 
process 500 of the StarODS CDG component 430 of the data 
warehousing infirastructure of the invention. With regard to 
FIGS. 8 and 9, the call processing/traffic component 405 
performs the following steps: receiving binary switch 
records from switch Adjunct Processors and Storage and 
Configuration elements ("SAVE") 402; translating switch 
records from binary to EBCDIC format so they can be read, 
for example, by an IBM mainframe; determining the date 
and time of each switch record; expanding on the record; 
calculating call duration and adds to each record; validating 
each record to determine if it is billable, and dropping 
unbillable records; validating each record to determine if it 
is billable, and, dropping unbillable records; determining the 
switch type and adding NPA/NXX information; determining 
the call type; determining which division each record 
belongs to, i.e., which data center from among one or more 
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processing datacenters should receive the record if a plural- 
ity of data centers exist; determining service type; perform- 
ing distance calculations; identifying and segregating any 
billable calls with errors and adding these records to a 

5 "error" file, for example, for future processing; adding the 
account number and billing cycle to each record; and, 
pricing all records destined for NCBS 410 at tariff. 

The NCBS component particularly produces new daily 
call detail feed files 522a, 522b for MCI Vnet/Vision 

10 customers, e.g., generated by product and divisional run- 
stream. Tollfree processing system 420 also creates new 
daily call detail feed files 522c by product and divisional 
runstream. 

With regard to the daily mainframe server extract process 

15 500 shown in FIG. 8, the first step 502 is triggered by the 
availability of a customer selection list file which, in the 
preferred embodiment, represents those nMCI Interact cus- 
tomers entitled to receive priced call detail data via their web 
browsers and consequently, which customer BDRs are to be 

20 extracted. Specifically, the CDG component is a mainframe 
process running at a primary datacenter which first executes 
an FTP pull of the customer list file from the nMCI Interact 
StarOE server 280, as indicated at step 504, and receives the 
updated customer file list at step 505. This customer list file 

25 may be used to drive subsequent extract processing at other 
data centers (not shown). In the preferred embodiment, the 
extract granularity in the daily customer list file is to the 
service location level, allowing extract of subsets of cus- 
tomer data down to service location level. Once retrieved 

30 from the StarOE server 280, the customer selection list may 
be transferred via network data mover "NDM" to the CDG 
extract processes which may be awaiting this file at other 
datacenters to trigger BDR extract processes at those other 
centers, assuming daily billing feeds are available at those 

35 data centers. In the preferred embodiment, the StarOE 
customer selection list file is used to extract Vnet, Vision, 
and Tollfree daily billing call data records for nMCI Interact/ 
StarODS priced reporting customers from the daily feeds 
from Tollfree/NCBS. Daily BDR's are available by division 

40 for Tollfree and by runstream from NCBS (Vision/VNET). 
The various divisional/runstream files may be consoli- 
dated in each CDG extract process, to generate a single 
extracted daily data file 523 per division in a data center. 
Furthermore, as indicated at step 506, a customer delta file 

45 is created which comprises a list of the Dew nMCI Interact 
priced reporting customers who were not in the previous 
day's customer selection list file. This customer delta file is 
backed up to at step 508 and, as indicated at step 510, may 
be transmitted to other data centers, e.g., for reporting 

50 purposes, or, to enable synchronization among the one or 
more datacenters. 

As shown in FIG. 8, a determination is made at step 511 
as to whether the number of new customers in the customer 
delta file has exceeded a predetermined threshold, e.g., 

55 greater than a 20% addition. If a threshold is exceeded, the 
extract process terminates until a manual override is per- 
formed to check out confirm the variance. Otherwise, the 
process continues at step 512. 
At step 512, the customer file may be further broken down 

60 into billing products, e.g., Toll free, Vnet, and having 
product identifiers such as Corp ID or Service ID, and may 
be loaded into a virtual storage access ("VSAM") system for 
enabling quick retrieval, as indicated at step 514. 
As CDG mainframe daily and monthly extract processing 

65 are triggered, on a division basis, by the completion of the 
appropriate corresponding billing daily or monthly division 
job(s), CDG maintains an audit point based on data extracted 
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on a daily or monthly basis. Audit totals are used to match 
back to billing summary totals which may trigger a monthly 
data replace operation, as will hereinafter be explained in 
greater detail. CDG also provides summary totals by cus- 
tomer to be used to verify data harvesting and database load 
totals. 

Next, as indicated at step 523, the raw billing detail 
records are input from the runstreams, e.g. Toll free, and a 
reconciliation is performed at step 528 to ensure that all 
BDR records from the runstreams are received files for the 
current customer list. Then, as indicated at step 530, the 
extract process is performed for the BDR datasets as they 
become available from the run streams. In the preferred 
embodiment, a SyncSort process is used to select only the 
customer data needed by the nMCI Interact StarODS system 
based on the customer selection list. Particularly, certain 
fields of the daily feed file are rearranged, and a value, e.g., 
determined by the production run date, is written to each 
daily record processed in the billing period and is used by 
the DSS in the data load process to replace daily records 
with their audited, final monthly counterparts, as will be 
explained. As part of extraction, the fields in each record are 
rearranged to the format usable by the DSS server, and 
identical to those produced by the daily process. In the event 
that invalid data types are encountered, the invalid data is 
replaced with designated valid values and invalid fields of 
any records may be blocked out based upon pre-determined 
criteria. Additionally input to the BDR record is an invoicing 
period value, e.g., "bill_period" which may be used as a text 
tag, to facilitate the above-mentioned monthly replace 
operation. More particularly, BDR records are rearranged so 
that the Corp ID, Service ID, Invoicing Period, Call Minutes 
and Call Amount are the first five fields of each record. 
Output BDR records are adjusted to have a structure and size 
which corresponds to the monthly data and, preferably are of 
constant length. In the preferred embodiment, the output 
BDR records have a constant length per record, with the 
output file defined as a variable blocked file with a record 
length of, for example, 1024 bytes. This allows dissimilar 
BDR output files to be concatenated for later reporting 
purposes, i.e., records produced by Vision may be com- 
mingled and reported with records from VNET or Tollfree. 

As previously mentioned, for the monthly audit process, 
the final step is the production of an audit file which is used 
as a control by the data Harvest process. This is accom- 
plished by reading in the processed BDR extract file and 
producing an audit file comprising all of the Corp ID & 
Service ID combinations for which BDR data was extracted, 
and the record counts, total minutes and total amounts for 
these records. 

As further shown in the FIG. 8, there is shown a CADB/ 
Geography build process 518 which receives a calling area 
database file (CADB) file 426 input from the StarOE server 
and a Vnet billing system City Name file input to determine 
if new records need to be added to a NPA/NXX dimension 
table. This is accomplished by first SyncSorting the CADB 
file down to unique country code, NPA, Nxx, bill_code, 
City Name, and State Code combinations. The CADB file is 
read and compared to the NPA/NXX table and the country 
code (CC), NPA, NXX, City Name, and State Name are used 
to see if that exact combination exists. If it does not, then it 
will be added to the NPA/NXX table and added to the 
dimension add file. A Key Sequence file (not shown) may be 
used to generate the key. Then, the billing system name file 
is read and bill code, City Name and State Code, will be 
compared against the NPA/NXX tables bill code, City2, and 
State Code. If the exact combination does not exist then it 
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will be added to the NPA/Nxx table and the dimension add 
file, using the Key Sequence file to generate the key. 
Continuing with the process, a SyncSort may be used to sort 
the NPA/NXX table first by NPA/Nxx, then by City2. 
5 Finally, the dimension add file is FTP'd to the database 

j)££ erver 

As mentioned, the ODS Data Harvesting Agent 600, e.g., 
Prism™ Warehouse Executive, is the component of the 
Priced Reporting system that focuses on the transformations 

10 and manipulations of billing data. Harvesting is the set of 
functionality that describes the form raw billing data must 
assume to be useable by customers to satisfy their questions 
and analysis requests. Common data gateway (CDG) main- 
frame system extracts raw Billing Detail Records (BDRs) 

is for those entided NMCI Interact/ODS customers, arid Data 
Harvesting transforms the Billing Detail Records based on a 
set of business rules applied to the call data. The final result 
of harvesting is call detail data ready to be loaded into the 
ODS data marts for customer access and analysis. 

20 Like the extract process, daily data harvesting is accom- 
plished on a divisional/runstream basis, distributed across 
one or more datacenter mainframe sites. It is triggered by the 
completion of the corresponding division extract in the CDG 
mainframe extract process at the data center. During data 

25 harvesting the extracted billing call detail records are trans- 
formed based on the star-schema data model, which incor- 
porates a central Fact table of call records surrounded by 
appropriately (foreign key) referenced satellite dimension 
tables. All dimensional table elements are available prior to 

30 harvesting as dimension-based lookups and, preferably, har- 
vesting logic enables creation of new dimension keys for 
any dimension value(s) not found in dimension lookup 
tables. 

As illustrated in FIG. 9, the data model 759 implemented 

35 in StarODS is a dimensional or "star schema" model, 
including a central fact table multiply joined to a number of 
attendant tables, i.e., dimensions. The relationships between 
the fact table and the dimensional tables are either enforced 
through keys, which may be generated, or as lookup codes. 

40 As shown in FIG. 9, the central fact table 761 is known as 
"Perspective Base" and provides access to a collection of 
attributes or facts concerning a call. The dimensional tables 
include the following: an Access Termination table 762 
comprising data indicating whether a call was charged to 

45 recipient (inbound) or originator (outbound); an Access 
Type table 764 comprising data indicating the type of access 
(for outbound calls) or egress (for inbound calls) character- 
istics of a call; a Billing Corp table 766 comprising data 
indicating the hierarchical status of a customer for the 

50 purposes of billing charges for products and features; a Toll 
Free Number table 768 comprising toll-free numbers i.e., 
800# or 888# (in the USA); a Product Type table 769 
comprising data indicating the product for which services 
are bundled for the purpose of invoicing; a GMT table 771 

55 comprising date and time data adjusted to the Greenwich 
Mean Time Zone; a LST table 773 comprising date and time 
data adjusted to the local MCI switch which permitted 
access to the MCI network; an Orig_Geo table 776 com- 
prising data indicating the geographic characteristics of a 

60 call's origination; a Term_Geo table 777 comprising data 
indicating the geographic characteristics of a call's termi- 
nation; a Report Geo table 778 comprising data indicating 
the geographic characteristics of a call's origination or 
termination; an Idacc table 779 comprising data indicating a 

65 customer's defined id and/or accounting code; a Data Stream 
table 781 comprising data relating to the line speed charac- 
teristics of a data (non-voice) call; a Pay Phone table 782 
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comprising data denoting calls originating from a payphone; previous day's StarOE customer list file, provides the basis 

a Usage table 783 comprising data indicating the geographic for a Billing/Customer Dimension "build" process. That is, 

attributes of a call which affect Tariff rates; an EVS Product since Billing/Customer is a dynamic dimension which incor- 

table 784 . comprising data representing Enhanced Voice porates new customer list records into the previous day's 

Services products; a Directory Assistance table 786 com- 5 Billing/Customer Dimension Lookup File. The newly 

prising data indicating those calls requesting Directory assis- updated Billing/Customer Dimension Lookup File is subse- 

tance; a Range table 787 comprising data indicating distance quently used by the harvesting programs to associate the 

bands a call may fall into; an NCR table 788 indicating appropriate Billing/Customer Dimension keys with the cor- 

Network Call Redirect calls; a Cell Phone table 789 com- responding central fact table records being generated, 

prising cellular call characteristics data; a VOS table 791 10 The association of dimension tables to a centralized fact 

indicating Voice Operator Services calls; a Conference Call table through a foreign key structure is created for each 

table 792 having data pertaining to characteristics of con- defined dimension or dimensional lookup, and is graphically 

ference calls; a Cross Corp table 793 comprising data represented in FIG. 10 by the simplified example as follows: 

indicating inbound cross corporate routing of calls; a Cur- As shown in FIG. 10, each record 602a, 6, ... of the 

rency table 794 indicating the unit of currency for call 15 extracted BDR 604 includes the Corp ID field 605 along 

prices; a card table 796 comprising data for billing calls to with other arranged data pertaining to that particular call, 

a location that may not be the one which originated the call; e.g., date, time, call amount. An example billing/customer 

an NCT table 797 comprising data representing Network dimension table 610 and Date dimension table 612 are also 

Call Transfers; an Amount Range table 798 indicating call shown in FIG. 10. In the example, the billing/customer 

usage ranges based upon amounts; and, a Duration Range 20 dimension table include keys 614a, and 614£>, corresponding 

table 799 indicating call usage durations based on amounts. to respective customers Corp ID 1, Corp ID 2. The date 

This star schema model is optimized for decision support dimension table includes date keys 616a and 6166, corre- 

and the retrieval of large amounts of data. Appendix H sponding to respective dates Jul. 1, 1998 and Jul. 2, 1998. 

provides the data attributes of each of these dimension After running the BDR 604 against the dimension tables 

tables. As known, in the dimensional model, the grain of 25 610, 612 as shown in FIG. 10, the harvesting process 

data stored in the fact table determines what level of data can generates a FACT table record 620 having a mix of dinien- 

be drilled down into. It should be understood that the grain sion keys, e.g., 614a, 616a, and data corresponding to the 

of the data stored in the Perspective Base table is at the extracted BDR. The combination of these entities represents 

singular call level. how data is to be stored in data marts for the operational data 

In the preferred embodiment, all dimension lookup tables 30 store component of StarODS and, further enables subse- 

must be built. Dimensions, such as Access Type Dimension, quent queries against the data to be formed by the decision 

Product Type Dimension, and Date-time Dimension, are support servers. In the preferred embodiment, the granular- 

manually built one time prior to migration to production and ity of the data in the fact table or "Perspective base," is at the 

are infrequently, if ever, updated, and are hence referred to singular call level. 

as static dimensions. The Access Type and Product Type 35 According to the invention, harvesting of daily and 
Dimensions are updated or added to only as new business monthly customer billing data for Priced Reporting may 
requirements are brought to light. For example, the Access occur in a distributed manner, i.e., across many production 
Type Dimension is updated only if new access types are data centers or wherever an upstream billing systems and 
created or added and, the Product Type Dimension is data processing takes place. Like upstream billing systems 
updated only if new products are supported by nMCl 40 and the Common Data Gateway, extract processing and data 
Interact priced reporting. The Date-Time Dimension on the harvesting may be distributed across these data centers by 
other hand may be updated, or rebuilt each year. geographic-based divisions and runst reams. Product and 
The remaining dimensions, such as, the Billing frequency typically distinguish harvesting processing. While 
Dimension, Geography Dimension, 800 Number the basic process logic is similar for all products regardless 
Dimension, the Calling Card Dimension, and the ID and 45 of whether it involves daily or monthly data harvesting, 
accounting codes ("IDACC") Dimension (if implemented), different dimensional processing as well as distinct business 
are dynamically built and maintained by the harvesting rules implementation are associated with each distinct prod- 
programs. Thus, if a lookup to one of these dynamic uct. As such, distinct data harvesting program modules are 
dimensions encounters a "Not Found" condition, the offend- implemented for each of the following: Daily data; Monthly 
ing call record may be pended to an unprocessed calls file in 50 Vnet data; Monthly Vision data; Monthly domestic Tollfree 
the same format as input by the harvesting program. In that data; Monthly international Tollfree data; and, Monthly 
scenario, the dimensional value that was not available in the CVNS data. 

lookup dimension is written to a dimension delta file which ~ ^ The daily harvesting process will now be described with 

may be later used to update that dynamic dimension. The \ reference had to FIG. 11. For purposes of explanation, it is 

pended and unprocessed call records may then be rerun 55 assumed that Fact and Dimension tables are being created 

through the same Harvesting process. In this way, these for Tollfree and/or Vnet/Vision BDR records (daily and 

dynamic dimensions are automatically maintained and monthly). As mentioned, the daily data harvesting process is 

updated by harvesting processes. In the preferred triggered to run the moment the customer list file fromthe 

embodiment, a new key is generated and the dimension table Common DAta Gateway mainframe becomes available. The 

automatically updated when a dimension look up can not be 60 program is triggered to run the moment the BDR file from 

found, thus obviating the need to create delta files and the Extract process becomes available. In a first step, the file 

running these unprocessed records a second time through is opened and the extracted and modified billing detail 

harvesting. Note that if a look-up to a static dimension is not record is read. Then, the following steps are performed to 

found, that record may be rejected. write dimension data to the (FACT) record, and/or to add a 

For example, after availability of the StarOE customer list 65 record to each Dimension table: first, as indicated at step 

file, a customer delta file provided during extraction and 625, a search is made in a "GEO Dimension Table — 

comprising all new customer list records added since the Originating" where the Geo (originating) Dimension is read. 
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If a matching record is found, the GEO RECORD KEY is It should be understood that similar daily harvesting 
moved to the created fact table (ORIG GEO RECORD procedures are implemented for those BDR records for other 
KEY); if no record is found, the CDG component preferably products besides Toll free, e.g., Vnet/Vision customers. For 
generates a new GEO RECORD KEY and moves it to the VISION/VNET (Monthly or Daily) the following steps are 
fact table. Otherwise, spaces may be written to the fact table 5 executed for each BDR record to create the Fact and 
(ORIG GEO RECORD KEY) and a "DELTA" record is Dimension tables: First, the file is opened and a billing detail 
written using GEO KEY Next, as indicated at step 630, a record is read: As an example, the following steps are 
search is made in a "GEO Dim Table — Terminating" where performed to write a billing dimension key to the (FACT) 
the Geo Dimension (Terminating) is read. If a matching record, or to add a record to each dynamic dimension table: 
record is found, the GEO RECORD KEY is moved to the first the following business rules are applied to the BILLING 
fact table. (TERM GEO RECORD KEY); if no record is Dimension Table: 1) Moving STK-ENT-ID-CD to BILL- 
found, the CDG component preferably generates a new ING KEY CORP; 2) moving STK-BILL-ID to BILLING 
GEO RECORD KEY and moves it to the fact table. KEY BILL (If STK-BILL-ID-SPACES MOVE ZERO); 
Otherwise, spaces may be written to the fact table (TERM and, 3) moving SVC-LOCN-ID to BILLING KEY 
GEO RECORD KEY) and a DELTA record is written using SVCLOC. Then, the BILLING Dimension is read. If a 
GEO KEY. Next, as indicated at step 635, a search is made 15 matching record is found, the BILLING RECORD KEY is 
in the Billing Dimension Table where the BILLING Dimen- moved to the Fact table (BILLING RECORD KEY). If no 
sion is read. If a matching record is found, the BILLING record is found, a new key may be generated for input to the 
DATETIME RECORD KEY is moved to the fact table fact table and billing dimension table (BILLING RECORD 
(BILLING KEY). If no record is found, the CDG harvest KEY). Each available file from the upstream billing systems 
component preferably generates a new BILLING RECORD 20 is processed as it is available. As a result, multiple runstream 
KEY and moves it to the fact table, otherwise spaces may be files are processed simultaneously, and Decision Support 
written to the fact table (BILLING RECORD KEY) and a Server 475 (FIG. 6) ftp pulls hundreds of daily files from the 
DELTA record written for the BILLING KEY. Next, as harvesting (Common Data Gateway mainframe), as indi- 
indicated at step 640, a search is made in a Calling Card cated at steps 669a, 6696 in FIG. 11. 
Dimension Table where the CARD Dimension is read. If a 25 Following completion of daily data harvesting processing 
matching record is found, the CARD RECORD KEY is for a given division or runstream but prior to file transfer and 
moved to the fact table (CARD KEY). If no record is found, load of division harvested data into the priced reporting 
the CDG harvest component preferably generates a new database(s), i.e., data marts, — all dimension adds for that 
CARD RECORD KEY and moves it to the fact table, division or runstream are transferred and loaded into the 
otherwise spaces are written to the fact table (CARD 30 appropriate database, as indicated at step 666. Other data 
RECORD KEY) and a DELIA record is written using transformations may occur prior to loading, for instance, 
CARD KEY. The look-up process continues for each call conversion of data from IBM Mainframe EBCDIC character 
detail product that is present in the extracted BDR including: set data to mid-range server readable ASCII file format is 
a look-up 645 in the local DATETIME DimensionTable performed for the output fact table records as indicated at 
(DATETIME KEY); a look-up 650 in the TOLLFREE 35 step 665. Additionally, the central BDR fact table records are 
NUMBER Dimension table (TFNUMBER RECORD properly formatted for querying by DSS. Finally, the Data 
KEY); a look-up in the IDAC Dimension table (IDAC Harvesting Process provides notification to the Priced 
RECORD KEY); a look-up in the USAGE Dimension table Reporting database servers) regarding availability and size 
(USAGE RECORD KEY); a look-up 655 in the GMT of harvested data files. It should be understood that, prior to 
Dimension table (GMT RECORD KEY); a look-up 660 in 40 data loading, an approval is required to ensure that appro- 
an ACCESS Dimension table (ACCESS RECORD KEY); a priate space is allocated to the databases, 
look-up 665 in the PRODUCT Dimension table (PRODUCT The FTP loading of various daily divisional/runstream 
KEY); a RANGE Dimension table look-up (RANGE harvested data files is initiated as soon as the data harvesting 
RECORD KEY); and, a DURATION Dimension table look- for a division or runstream is completed, as indicated in FIG. 
up (DURATION RECORD KEY). With respect to the GMT 45 11 at steps 669a,b. Daily harvested data files are transferred 
Dimension table, the "switch_trnk" field and the "switch_ or available in the datacenter in the appropriate ASCII file 
trnk_grp" field is taken from the BDR to find an offset, format. Furthermore, loading of a given monthly divisional/ 
which will be added to, or subtracted from, the time of the runstream harvested data file is triggered by the correspond- 
call. With respect to the RANGE Dimension table look-up, ing formal invoicing approval for that division or runstream. 
if a RANGE Dimension Finding Record Value is greater 50 Appendix I is a listing in DDL representing the star 
than (">") a RANGE KEY value, then the RANGE topology organization of the fact tables, dimension tables, 
RECORD KEY is moved to the fact table. Likewise, if a and their associations in the operational data storage devices 
DURATION Dimension Finding Record Value is greater or data marts, i.e., an Informix™ database. Included in the 
than (">") a DURATION KEY value, then the DURATION file listing of Appendix I, is the organization of the fact table 
RECORD KEY is moved to the fact table. 55 "informix.iopers__.base," associations with the above- 
As all Dimension tables are populated with keys, the described dimension tables in a star-schema relation, and, 
record is written to the FACT Table (FIG. 10). Otherwise, the format for the corresponding customer specific data 
the record is placed into suspense (DELTA) for reprocessing. information, e.g., dialed number, duration, call amount, etc., 
The process outlined above continues for each BDR record included in the fact table from the BDRs. The database is 
received in the bill stream. If dynamic dimension tables have 60 provided with ancillary tables used providing additional 
not been updated, then after all records are read, all dynamic quality assurance functionality including: a file tracking 
dimension tables are updated with the written deltas. If the table "mfonnix.file_tracking" which tracks and maintains 
file is complete the error file is read, and each record all files that are input from harvesting mainframe process; 
reprocessed to add dimension keys for each record. When and, request tracking tables "informix. re quest,'* 
the error file has been processed, the harvest process for that 65 Informix. request_hist" and " inform ix.request_status" 
file ends and notification is sent to the StarODS database which are used to track customer report requests and the 
server that "files are ready." status of reports during the report generation process. 
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With regard to the availability of monthly billing call 
detail records, the elements of the monthly extract, harvest, 
load and report production processes are the same as the 
corresponding daily routines. On days when a monthly 
processing is occurring, daily processing simultaneously 
occurs. The major difference is that monthly processing is 
triggered by the receipt of a monthly BDR rile from the 
appropriate billing system, not the receipt of daily customer 
list information. At a high level, the sequence is as follows: 
the monthly extract process runs; the monthly harvest pro- 
cess runs; monthly file sizing is completed; output files are 
retained pending audit approval of billing system feeds from 
which call records were extracted and harvested. Informa- 
tion about file names, sizes and locations is retained by the 
Harvest process 600 for later transmission to StarODS DSS 
server. After audit approval is received, the data harvesting 
agent executes notification of ODS. Notification includes 
availability, name, location and file size. StarODS load 
process executes ftp pull for each file and DSS confirms that 
each compressed file fragment is complete. DSS loads files 
in the appropriate operational data store or data mart by 
executing a replace operation of all daily records for that 
product, invoice period and day with their equivalent 
records from the monthly file. Granularity of the replace 
operation is on a daily level, i.e., daily blocks of BDR's are 
replaced, not individual BDR's. Completion of entire 
monthly replace operation for specific invoice period and 
product triggers the DSS server to begin running monthly 
reports which have been queued up. 

It should be understood, that the monthly replace opera- 
tion, is key to providing accurate data for use by DSS in 
reporting. 

More particularly, on a monthly basis, the priced reporting 
system extracts monthly billing data from the upstream 
billing systems, including NCBS and Tollfree. From NCBS, 
monthly division extracts are produced for Vnet and Vision. 
Monthly division extracts for domestic and international 
Tollfree are generated from the output of the Tollfree billing 
cycle. Extract of nMCI Interact specific call detail records 
from the full output of the billing system is accomplished on 
a divisional level. 

As part of the monthly extract process, a value determined 
by the production run date is added to the BDR, and is used 
by the DSS in the data load process to replace daily BDR 
records with their audited, final monthly counterparts. As 
part of extraction, fields in each record are re-arranged to the 
format usable by the DSS, and identical to those produced 
by the daily process. In the event that invalid data types are 
encountered, the invalid data is replaced with designated 
valid values. 

In addition, a statistical summary of the results of the 
Monthly Extract process is produced. This output is com- 
pared to the grand total of daily summaries produced by the 
daily extract process in the same billing period. The sum of 
daily BDR counts is compared to the grand total of BDR 
counts for the bill period/product/division, as well as daily 
counts from the daily process to daily counts per the monthly 
extract. This is done as a monthly reconciliation to ensure 
the completeness and accuracy of the monthly file prior to 
the monthly replace operation which is accomplished by the 
DSS server 475. 

Referring back to FIG. 8, after the daily and monthly 
harvest and monthly replacement operations have been 
performed, the data is input to an operational data store 
component ("ODS") 450 that stores the billing detail records 
and dimension tables as a data model. This ODS layer 450 
is comprised of all data harvested from all applications in the 
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data harvesting layer 430, and feeds report-supporting data 
marts 470 in a manner which supports customized data 
access. The data marts may be engineered to pre-process 
data, create aggregates, and otherwise perform transforma- 

5 tions on the data prior to data mart 465 in order to implement 
a defined data model, e.g., star schema key structures, fact 
and dimension tables depicted as block 460. In the preferred 
embodiment, as shown in FIG. 8, the Operational Data Store 
450 includes multiple datamarts 470 each for storing and 

10 retrieving daily and monthly priced data on a periodic basis. 
It primarily is responsible for hosting highly current data, 
typically at least 72 hours old. In accordance with customer- 
reporting needs, data marts 470 are partitioned in accordance 
with partitioning schemes which may be based on customer- 
is ID. Particularly, each data mart is engineered for servicing 
specific customers or specific product sets, as well as engi- 
neered for the specific requirements of the customer/product 
such as high insert activity, heavy reporting requirements, 
etc. As data is volatile and changing and may not produce 

20 consistent results for the same query launched at multiple 
rimes, ODS is engineered for high performance through 
appropriate storage technologies and parallel processing. 

From these data marts customer's priced reporting data 
can be provided to customers on a daily basis via the 

25 StarWRS reporting system as described in detail in above- 
mentioned co-pending U.S. patent application Ser. No. 
09/159,684, filed Sep. 24, 1998. Reporting categories from 
which a variety of reports can be generated include: a) 
Financial category — for providing priced data reports relat- 

30 ing to longest calls, most expensive calls, Off Peak Calls, 
payphone report, usage summary, calling card summary, and 
area code summary for Toll Free, VNET, Vision, and CVNS 
customers; b) Marketing category — for providing priced 
data reports relating to country code summary, state 

35 summary, frequent numbers, frequent area code summary, 
frequent state, and frequent cities; c) Telecommunications 
category — for providing priced data reports relating to call 
duration summary, IDAC/Supp Code Summary and Call 
Access Summary for Toll Free, VNET, Vision, CVNS 

40 customers; d) Call Center report category— for providing 
priced data reports relating to most active toll free numbers, 
Hourly Distribution, Day of Week Distributions, state 
summary, and country code summary for their Toll Free, 
VNET, Vision, CVNS customers; e) Monitor Usage — for 

45 providing priced data reports relating to longest calls, most 
expensive calls, most active calling card and most active toll 
free numbers for their Toll Free, VNET, Vision, CVNS 
customers; f) Analyze Traffic — area code summary, country 
code summary, state summary, range summary, city 

so summary, frequent numbers, payphone report, usage 
summary, calling card summary, IDAC/Supp Code 
Summary, Day of Week Distributions, Hourly Distribution, 
Call Access Summary and review calls; and, a g) Check 
Calling Frequencies category — for reporting on frequent 

55 numbers, frequent area code, frequent country codes, fre- 
quent state and frequent cities. 

Additionally, referring back to FIG. 7 there is provided a 
decision support server ("DSS") reporting engine compo- 
nent 475 that performs the following functions: 1) receives 

60 data access requests from various users in the form of a 
report request from the StarWRS GUI Report Requestor 
component; 2) routes the query to the appropriate data marts 
470, data warehouse or operational data store; and, 3) 
responds to the requestor with the result set. The DSS server 

65 475 may also perform cost estimation, agent scheduling, 
workflow broadcasting interface, and transaction logging 
functions. In the preferred embodiment, the DSS 475 is a 
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cluster of DEC (Digital Equipment Corp.) UNIX 8400 
servers running Information Advantage® software access- 
ing an Informix database distributed across multiple data 
marts. 

Thus, the present invention is integrated with a client and 
middle-tier service and application proxy component that 
enable customers to request, specify, customize, schedule 
and receive their telecommunications network call detail 
data and account information in the form of reports that are 
generated by the various back-end application servers. 
Referred to herein as "StarWRS," this WWW/Internet 
Reporting System 200, as shown in FIG. 12, comprises the 
following components and messaging interfaces: 

1) those components associated with the Client GUI front 
end including a report requestor client application 212, 
a report viewer client application 215 and, an Inbox 
client application 210 which implement the logical 
processes associated with a "Java Client," i.e., employs 
Java applets launched from the backplane (FIG. 4) that 
enable the display and creation of reports and graphs 
based on the fields of the displayed reports, and, allows 
selection of different reporting criteria and options for 
a given report; and, 

2) those middle-tier server components enabling the 
above-mentioned reporting functionality including: a 
Report Manager server 250, a Report scheduler server 
260, and an Inbox Server 270. Also shown in FIG. 7 are 
the system Order Entry client application 280 and a 
corresponding Order Entry Server 285 supporting the 
StarWRS reporting functionality as will be described. 

Each of these components will now be described with 
greater particularity hereinbelow. 

The Report Manager ("RM") server 250 is an application 
responsible for the synchronization of report inventory with 
back-end "Fulfilling" servers 400, 500; retrieval of 
entitlements, i.e., a user's security profiles, and report pick 
list information, i.e., data for user report customization 
options, from the system Order Entry server 280; the trans- 
mission of report responses or messages to the Dispatcher 
server 46 (FIG. 3); the maintenance of the reporting data- 
bases; and, the management of metadata used for displaying 
reports. In the preferred embodiment, the RM server 250 
employs a Unix daemon that passively listens for connect 
requests from the GUI client applications and other back- 
end servers and deploys the TCP/IP protocol to receive and 
route requests and their responses. Particularly, Unix stream 
sockets using the TCP/IP protocol suite are deployed to 
listen for client connections on a well-known port number 
on the designated host machine. Customers desiring to 
submit requests connect to RM 250 via the dispatcher 46 by 
providing the port number and host name associated with 
RM 250. For the particular back-end server 400 providing 
priced reporting data, a Talarian smart socket connection 
255 is provided. Request messages received by the RM 
server are translated into a "metadata" format and are 
validated by a parser object built into a report manager proxy 
250' that services requests that arrive from the GUI front- 
end. If the errors are found in the metadata input, the RM 
250 will return an error message to the requesting client. If 
the metadata passes the validation tests, the request type will 
be determined and data will be retrieved in accordance with 
the metadata request after which a standard response will be 
sent back to the requesting client. As shown in FIG. 12, 
interface sockets 252 are shown connecting the Dispatcher 
server 26 and the RM server 250 and, other socket connec- 
tions 254, 256 are shown interfacing the RM 250 with 
respective back end servers 400 and 500. For instance, in 
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one embodiment, fulfilling server 400 provides a customer's 
priced billing data through a Talarian smart socket messag- 
ing interface 254 to the Report Manager. Additionally, as 
part of the StarWRS web reporting system 200 shown in 

5 FIG. 12, unpriced traffic data may be sent directly to the 
report manager 250 from the Traffic View server ("TVS") 
500, as described in commonly-owned, co-pending U.S. 
patent application Ser. No. 09/159,684 entitled INTE- 
GRATED PROXY INTERFACE FOR WEB BASED DATA 

10 MANAGEMENT REPORTING TOOL. Although not 
shown in FIG. 12, it should be understood that the RM 250 
server may manage reporting data for customer presentation 
from other back-end and legacy servers including, e.g., 
Broadband, Toll Free Network Management, and Event 

15 Monitor servers, etc. in order to present to a customer these 
types of billing/management data. 

The report manager server additionally utilizes a database 
258, such as provided by Informix, to provide accounting of 
metadata and user report inventory. Preferably, an SQL 

20 interface is utilized to access stored procedures used in 
processing requests and tracking customer reports. A variety 
of C++ tools and other tools such as Rogue Wave's 
tools.h++ are additionally implemented to perform metadata 
message parsing validation and translation functions. 

25 The Report Manager server 250 additionally includes the 
scheduling information which is passed to the back-end 
fulfilling servers 400, 500 and stored by them. At times, the 
Report Manager will request this information from the 
fulfilling servers in order to reconcile. 

30 The Report Scheduler ("RS") server component 260 is, in 
the preferred embodiment, a perpetually running Unix dae- 
mon that deploys the TCP/IP protocol to send requests to the 
back-end fulfilling servers such as the StarODS server 400, 
or TVS server 500, and receive their responses. More 

35 particularly, the RS server 260 is a Unix server program that 
is designed to handle and process report requests to the 
fulfilling servers by deploying Unix stream sockets using the 
TCP/IP protocol suite, and sending the report request to 
client connections on a well-known port number on the 

40 designated host machine. As shown in FIG. 12, interface 
socket connections 264, 266 are shown interfacing with 
respective back end servers 400 and 500. In the case of 
priced billing data from ODS 400, report requests are 
published by the RS server 260 to a pre-defined subject on 

45 the Talarian Server. When handling other incoming mes- 
sages published by back end servers using Talarian Smart- 
Sockets 4.0, another daemon process is necessary that uses 
Talarian C++ objects to connect their message queue and 
extract all messages for a given subject for storage in a 

50 database table included in database 263. Each message 
includes the track number of the report that was requested 
from the fulfilling server. 

From the report scheduler interface, the user may specify 
the type of reporting, including an indication of the sched- 

55 uling for the report, e.g., hourly, daily, weekly or monthly. 
For priced data the user has the option of daily, weekly, or 
monthly. For real-time, or unpriced data, the user has the 
option of hourly, daily, weekly or monthly. The report 
scheduler interface additionally enables a user to specify a 

60 page or E-mail account so that an e-mail or page message 
may be sent to indicate when a requested report is in the 
Inbox server 270. 

As shown in FIG. 12, the report scheduler server 260 
interfaces directly with the Report Manager server 250 to 

65 coordinate report request processing. It should be under- 
stood that the respective report management and scheduling 
functions could be performed in a single server. An overview 
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of the report request/scheduling process implemented by priority message to get through even if a large download is 

StarWRS Report Manager and Report Requestor tools may in progress. Typically, the browser is configured to allow 

be found in commonly owned, co-pending U.S. patent more than one network connection simultaneously, i.e., the 

application Ser. No. 09/159,409, filed Sep. 24, 1998 entitled polling thread on the client uses a separate connection to 

INTEGRATED PROXY INTERFACE FOR WEB BASED 5 chec k for new messages, and start a new thread on a new 

REPORT REQUESTOR TOOL SET, the contents and dis- connec tion when a new message was detected. In this way, 

closure of which is incorporated by reference as if fully set multiple messages may be downloaded simultaneously, 

forth herein. , The Report Requestor application 212 is a GUI Applet 

The Inbox Server component 270 serves as the repository enabUn usef mteraction for managing reports and partic u- 

where the completed user report data is stored, maintained, , , . , , . /r , , 

j ii j i * j j ■ . /• j • , - 10 larly includes processes supporting: the creation, deletion, 

and eventually deleted and is the source of data that is , ^ * \* *t_ . • i j j- i 1 

uploaded to the client user via the dispatcher over a secure an , d of me u use ;. s T& ? GV * 1 of 

socket connection 272. It is also a Unix program that is * eIecled ******* display of selected option data; and the 

designed to handle and process user requests submitted in determination of entitlements which is the logical process 

metadata format using an Informix® database. Once report defining what functionality a user can perform on StarWRS. 

results are received from the StarODS 400 or any other 15 In the Preferred embodiment, a Report request may be 

back-end or fulfilling servers (not shown), the Inbox server executed immediately, periodically, or as "one-shots" to be 

270 requests the metadata from the Report Manager server performed at a later time. As described herein, the report 

250 as indicated by the socket connection 272 in FIG. 12. scheduler service maintains a list of requested reports for a 

The metadata is stored in the Inbox server database 273 given user, and forward actual report requests to the appro- 

along with the report results. Thus, if the metadata is 20 priate middle-tier servers at the appropriate time. Additional 

required to be changed, it will not interfere with the infor- functionality is provided to enable customers to manage 

mation needed to display the reports included in the Inbox. there inventory, e.g., reschedule, change, or cancel (delete) 

Additionally, as shown in FIG. 12, the Inbox server inter- report requests. 

faces with the report scheduler to coordinate execution and The Report Viewer application 215 is a GUI Applet 

presentation of reports. 25 enabling a user to analyze and display the data and reports 

The StarOE server 280 is the repository of user pick lists supplied from the fulfilling servers such as StarODS 400, 

and user reporting entitlements as shown in database 283. Traffic Mew ("TVS") 500, and other systems such as 

Particularly, it is shown interfacing with the Inbox server Broadband and toll free network manager. Particularly, the 

270 and report scheduler servers 260, The Report Manager Report Manager 250 includes and provides access to the 

does not interface with or include metadata for StarOE. It 30 metadata which is used to tell the Report Requestor what a 

will, however, include information in the report metadata standard report should look like and the "pick- list" options 

that will tell the Report Requestor it needs to get information the user has in order for them to customize the standard 

(i.e., Pick Lists) from StarOE server 285. Particularly, the report. It is used to tell the Report Viewer client how to 

StarOE server supports pick lists for the selection of priced display the report, what calculations or translations need to 

data based on the following list: Date, Time (Provide in 35 be performed at the time of display, and what further 

GMT offset), ID Accounting Code (IDAQ/Supp code, customization options the user has while viewing the report. 

Access Type, Corp ID, Service Location w/Service Location It additionally includes a common report view by executing 

Names, Bill Payer w/Bill Payer Names, 8XX Number, City, a GUI applet that is used for the display and graphing of 

State/Province, Numbering Plan Area (NPA), NXX report data and particularly, is provided with spreadsheet 

(Exchange code where N-2-9 and X«4)-9), and Country 40 management functionality that defines what operations can 

Code. be performed on the spreadsheet including the moving of 

With regard to the front-end client GUI components, the columns, column hiding, column and row single and mul- 

above-mentioned Inbox client application 210 functions as tiple selection, import and export of spreadsheet data, and 

an interface between the client software and the Inbox server printing of spreadsheet, etc. It is also provided with report 

270 for presenting to the customer the various type of reports 45 data management functionality by defining what operations 

and messages received at the Inbox including all completed can be performed on the data displayed in a spreadsheet 

reports, call detail, alarms, and flashes. Preferably, the including such dynamic operations as sorting of report data, 

messages for the user in the inbox is sorted by type (e.g., sub-totaling of report data, etc. Furthermore, the report 

report, call detail, alarms) and then by report type, report viewer 215 is provided with functionality enabling the 

name, date, and time. A more detailed description of the 50 interpretation of metadata; and, functionality enabling com- 

StarWRS Inbox Server component may be found in munication with the Backplane (FIG. 4). The report viewer 

commonly-owned, co-pending U.S. patent application Ser. application 215 is able to accept messages telling it to 

No. 09/159,512, filed Sep. 24, 1998 entitled MULTI- display an image or text that may be passed by one of the 

THREADED WEB BASED USER IN-BOX FOR REPORT applications in lieu of report data (e.g., Invoice, Broadband 

MANAGEMENT, the contents and disclosure of which is 55 report, etc.) 

incorporated by reference as if fully set forth herein. All reporting is provided through the Report Viewer 
Particularly, the Inbox client application uses the services interface which supports spreadsheet, a variety of graphic 
of the backplane (FIG. 4) to launch other applications as and chart types, or both types simultaneously. The spread- 
needed to process report messages. The inbox will also use sheet presentation allows for sorting by any arbitrary set of 
the services of the data export objects to provide a save/load 60 columns. The report viewer 215 is launched from the inbox 
feature for inbox messages, and, is used to provide a client 210 when a report is selected and may also be 
user-interface for software upgrade/download control. Inbox launched from the inbox when a report is selected, 
messages are generated by the versioning services of the By associating each set of report data which is down- 
backplane; actual downloads will be accomplished by a loaded via the Inbox server 270 with a "metadata" report 
request through the inbox. 65 description object, reports can be presented without a report- 
In the preferred embodiment, the inbox client is able to specific presentation code. At one level, these metadata 
receive information on multiple threads to allow a high descriptions function like the catalog in a relational 
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database, describing each row of a result set returned from 
the middle tier as an ordered collection of columns. Each 
column has a data type, a name, and a desired display 
format, etc. Column descriptive information will be stored in 
an object, and the entire result set will be described by a list 
of these objects, one for each column, to allow for a standard 
viewer to present the result set, with labeled columns. 
Nesting these descriptions within one another allows for 
breaks and subtotaling at an arbitrary number of levels. The 
same metadata descriptions can be used to provide common 
data export and report printing services. When extended to 
describe aggregation levels of data within reporting 
dimensions, it can even be used for generic rollup/drilldown 
spreadsheets with "just-in-time w data access. 

The metadata data type may include geographic or 
telecommunications-specific information, e.g., states or 
NPAs. The report viewer may detect these data types and 
provide a geographic view as one of the graph/chart types. 

As mentioned herein with respect to FIGS. 7 and 12, the 
StarODS component 400 interfaces with StarWRS web 
reporting tool 200 for specific customer reporting require- 
ments. As described, the Report Requester 260 communi- 
cates with the user client 201 and controls navigation and 
requests for customization criteria via the Web browser. The 
Report Requestor receives from StarOE any billing hierar- 
chies and static pick lists needed by the client to customize 
report requests. Report request customizations are then 
passed to the Report Manager, which acts as repository of 
report requests, both adhoc and recurring, that are submitted 
for processing by the client. Along with the necessary 
customization criteria selected for report customization, the 
Report Manager 250 stores metadata about the report 
request, including report format information, sort, and dis- 
play specifics. The Report Manager is responsible for pass- 
ing report requests to the back end DSS and data marts for 
processing, and provides the entity against which the list of 
report requests known to the data marts are validated. 

The Inbox server component 270 is the store and forward 
repository of all completed reporting requests, requests for 
call detail data, and any communications to the customer. As 
will be described, the Decision Support Server 475 ships 
formatted data in a compressed comma delimited format 
("CDF") to the Inbox. Customers are then responsible for 
retrieving their report data held in the Inbox. 

In accordance with the invention, the primary function of 
the DSS 475 is to generate priced billing report data in 
accordance with the customer's request. To accomplish this, 
the DSS interfaces with two StarWRS systems: Report 
Manager 250, and Inbox 270, as shown in FIG. 7. The 
Report Manager formats the customer's request in accor- 
dance with a defined set of rules and sends the request to the 
DSS. The DSS 475 reads customer's requests which are 
metadata descriptions of the type of priced data report 
requested by a customer, translates the metadata into data- 
base queries, and implements commercial off-the-shelf 
("COTS") tools to run the queries against the data in the data 
marts, format the query results into a form readable by 
StarWRS report viewing components, and transmits the 
completed reports to the directory of the customer's Inbox, 
e.g., via FTP. In the preferred embodiment, Talarian Smart- 
Sockets™ messaging middleware is used to coordinate 
report requests transmitted from the StarWRS report Man- 
ager to DSS, and report completion notification from DSS to 
the StarWRS Report Manager. The Report Manager formats 
the customer's request in accordance with a defined set of 
rules and sends the request to the DSS as a Talarian message 
with the Report Manager 250 maintaining the Talarian 
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Sender program, and the Decision Support Server 475 
maintaining the Talarian Receiver program. Messages are 
sent with guaranteed message delivery ("GMD"), thus 
assuring all request data sent by RM is received by the DSS. 

5 As depicted in greater detail in FIG. 13(c), a Report 
Manager/DSS application programming interface "API" 
480 is provided whereby the RM server 250 publishes the 
message to the Decision Support Server in response to its 
receipt of a report request. Subsequently, the DSS 475 

10 returns a "Message Received" message. When the DSS has 
processed the request, it publishes the message to the RM 
250 with the name and location of the report file or an error 
message to the Report Manager, via an "NRL" metadata 
message as described herein. 

15 FIG. 13(6) illustrates an DSS/Report Manager application 
programming interface "API" 485. In the preferred 
embodiment, all return messages are persistent. Thus, as 
shown in FIG. 7 the DSS incorporates a Talarian message 
queue 490 operating on a First-In-First-Out (FIFO) basis. If 

20 the DSS is unable to establish the connection with Talarian, 
or there is an error in transmission, the DSS queues all 
messages, and continues to retry until a successful send is 
executed. 

Similarly, a DSS/Inbox API is provided to manage FTP 
25 file transmissions including: error handling, retry logic, and 
the ability to maintain the file name and location of where 
report files are stored. Particularly, the DSS/Inbox API sends 
the report file to the inbox (FIG. 7). If the DSS has generated 
an error condition, and the report is unable to be generated, 
30 an error message will be sent to the inbox in place of the 
report file. In either case, a return message will be delivered 
to the DSS/Report Manager API 485 indicating a successful 
or unsuccessful generation and transmission of the report 
file. 

35 More particularly, as shown in FIG. 15(a), an RTServer 
process 377 is provided for maintaining connections, ensur- 
ing guaranteed message delivery, and tracking the success of 
all messaging operations. As the Report Manager interfaces 
with multiple systems, the RTServer 377 processes are 

40 located in the RM. The DSS is provided with RTClient 
processes 377a,b that provides the API to RTServer: one 
RTClient 377a for providing the API to Report Manager for 
receiving messages; and, a second RTClient 377/) for pro- 
viding the API for the NRL. However, it should be under- 

45 stood that other ODS boxes can have one RTClient. The RM 
and Arbitrators 360a,6 use the GMD feature of Talarian to 
deliver messages. RM/Inbox communication is not affected 
by outages of ODS server as the arbitrator and ODS com- 
munication is independent of RM/Inbox communication. 

50 In the preferred embodiment, the DSS architecture is 
transparent to the Report Manager which publishes Talarian 
messages to which the DSS will subscribe. In addition to the 
tokenized character string request message which specifies 
report type, filters, and any customer request-specific 

55 information, RM server provides additional fields as part of 
the Talarian request message including: a Corp_JD, Priority, 
and RequestlD. Corp_ID allows the DSS to route the 
request to the appropriate data store without having to 
invoke a parser. Data are partitioned on Corp_ID in the 

60 ODS database warehouse. Request_id is used to send back 
an ARDA failure message, in the event of an invalid 
message. The Priority field allows DSS to pickup the next 
high priority request from a queue of non-processed 
requests, without invoking the parser. 

65 FIG. 14(b) illustrates the implementation of the COTS 
Information Advantage® Interface Object ("IAIO") 372, 
which is a process running in the DSS 475 for performing 
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the following functions: 1) publishes and subscribes Talarian "stdrptid" which identifies each report and is similar to 

messages to Report Scheduler; 2) parses the request meta- column id's but on the report level; "userptid" which is the 

data ARD (Add Report Definition) message; 3) publishes an user-assigned identifier for a report request; "compress" 

ARDA (Add Report Definition Acknowledgment); 4) popu- having possible values ' l'-yes, £ 2'-no indicating if a report 
lates a request table 390 with total, sub-total and sort 5 * to be compressed, e.g., using a standard zip routine; 

information according to the received report request; 5) "threshold" defining the number of lines that shall appear on 

transforms the ARD tokens from the metadata request into me rc P° rt i "totalmode" which defines how the report shall 

an overlay file 392 which is a text file that is submitted to be ™£d> subtotaled as indicated by possibk values 0 -No 

IA's Decision Suite™ pr0 cess to generate the corresponding ™* No .^*H I m ^ ^ l0 f > , 2 = ° nly f Toial '> 3 " 
PAr ^ * . n r * e* * « i_i <*fti • « Total and Subtotal; nrl totals indicating the formatter to 

SQU; 6) updates a Request Status table 39! with appropn- 10 ^ fa ^ ^ ^ ^ 

ate status e.g process complete, failed, in progress, etc.; arenumericandha ; easubtotal fl ag .. y . inacolumnidtable; 
and, 7) tf a failure occurs, it updates an error log (not .. formal _ columns » which define derived co^ns on which 

shown). percentages are to be calculated; "error_code" for indicat- 

More particularly, in view of FIG. 14(6), ARD metadata ing parser failure or system failure u it > s a parser failure 

request messages are received into the ODS system via 15 condition, the code is returned to Report Manager; "error__ 

arbitrator processes 360^6 which are responsible for routing desc" indicating the error description; and, "rpmgr_ 

the request message to the appropriate ODS database columns" which are the columns sent to the DSS by Report 

according to a Corp/ODS mapping table 365. Report Man- Manager. The formatter checks this list against the list in the 

ager publishes a single message subject "Arbitrator" having .hdr file. 

the above-mentioned request, Corp_ID, and Priority field 20 Similarly, the Request_Status table 391 provided in 

information. Report Manager uses a round robin message Appendix J is populated to include the status of the different 

delivery mechanism complemented by Talarian's GMD to processes including: "Request_Id," i.e., the unique identi- 

publish messages to the subject Arbitrator 360a,/?. The fier for the request, "Priority," e.g., having a value of "1," for 

arbitrator extracts the Corp_ID field from the message and example, meaning adhoc; a "timestamp" which is the Infor- 

maps the Corp ID to corresponding ODS DataMart in the 25 mix Date Time that will be used when two or more messages 

table 365 it maintains. The arbitrator then republishes the have same priority; and "Status** which is a char message 

message with the ODS#. As shown in the FIG. 11(6), a including the following status fields: "new_jnessage" indi- 

second arbitrator process 3606 is provided to assure fail- eating that a new message has arrived, yet to be processed; 

over capabilities. "in_IAIO" status indicating that the message is being 

In FIGS. 14(a) and 14(6), a Talarian receiver, referred to 30 processed by interface process IAIO; "parser_failed" status 

herein as a Talarian Interface Object ("TIO") 370, is a indicating an Invalid message from RM. NRL process sends 

process that receives the Talarian message, manages the a ARDA error message; "parser_success" status indicating 

GMD functionality, and posts updates to the request table that the message from RM is a valid message. NRL process 

390 and request status table 391. As shown in FIG. 14(6), the would send a ARDA message to RM; "IAIO_complete" 

TTO receivers 370 subscribe to a subject "ODS#." The 35 status indicating that the report has been generated and 

receiver inserts the message received from the arbitrator into directory and file name fields are modified. Formatter can 

the request table 390 and request status table 391 along with pick up this message; "IAIOJailed" status indicating that 

the priority, timestamp and status fields. The request status IAhas failed to generate a report, i.e., an error has occurred 

table resides on the ODS database and the messages are generating a report; "in_formatter" status indicating that the 

stored in the queue to provide queuing, log and tolerance 40 formatter is converting the text file generated by IA to a 

from the failures. To determine the pending messages to be comma delimited format. The formatter may also, if 

processed, status field and history_stat flags are used. required, does the percent (%) calculations, e.g., subtotals 

Appendix "J" illustrates the contents of the ODS Request etc.; "format^success" status indicating that the formatter 

table 390 and Request Status tables 391, which are part of successfully completed translation of the file. It also popu- 

the ODS database. 45 lates the inbox file name, inbox file directory, nrl total 

In the preferred embodiment, the tables provided in (optional) fields in the table; " forma t_failed" status indi- 

Appendix J include: an "informix".request table 390 (FIG. eating that the formatter failed to translate the text file 

14(a)) which is the table maintained for the purpose of generated by IA; "in_ftp". status indicating that the ftp 

holding specific report request information from the process is currently sending the file to inbox; "ftp_suceess" 

received ARD message, and, an "informix".req_status for 50 status indicating that the file generated by formatter is ftp'd 

holding status of DSS processes for the current request. to inbox; "ftp_J:ailed" status indicating that the formatted 

Thus, for the example ARD message provided in Appen- file could not be ftped to inbox; "in_NRL" status indicating 

dix J, the request table 390 will be populated to include: a that the NRL process is trying to send either ARDA message 

"request_id," which is the unique identifier for the request; or NRL message to RM; "NRL_sent" status and "ARDA- 

a "msg_desc," representing a copy of the ARD message; 55 sent" status indicating that the respective NRL or ARDA 

"unique__fiiame," which is the unique name assigned to message has been sent to RM. Each DSS process updates the 

each request to enable tracking of individual report requests request status table as it processes. 

and is additionally assigned to the report returned to the A further "history^stat" field may be provided in the 

report manager; a "report_dir" indicating the location of the request_status table 391 having a value, e.g., 4 A* (Active) 

report that Decision Suite™ generates (which may be a tab 60 indicating that the record needs to be processed, or, indicat- 

delimited^report file); "format__dir" indicating the location ing *H* (History), when the record is no longer active and 

where the report formatter generates (comma delimited file); needs to be archived in a separate database set up for 

"inbox_dir" indicating the location on the Inbox (Report archival purposes (not shown). 

Manager) where the report is sent; "inbox_fsize" indicating As further shown in Appendix J, there are two more tables 

the size of the file; "entpid," indicating the Enterprise id 65 that are defined for DSS sorting and formatting processes: a 

which may consist of one or more corporate id's; "userid" Column ID Table, and a Translation table which are tables 

which is an identifier assigned to each user of the system; configured for the formatter process, as will be described. 
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As further shown in FIG. 14(6), in operation, each Infor- 
mation Advantage® Interface Object ("IAIO") 372a,fc, . . . 
n reads the status table 391 for new entries. When a new 
entry is posted, it invokes a parser process 393, and invokes 
the Information Advantage® SQL generator engine which 5 
retrieves the requested data from the database, and updates 
the status table 391. 

Particularly, the Decision Suite™ tool receives the over- 
lay file (FIG. 14(a)) and performs the following functions: 

1) generates SQL; 2) submits the SQL to the appropriate 10 
datamart (ODS database); 3) generates a Report file with a 
"Vtxt extension; 4) updates Request Status table 391 with 
appropriate status; and, 5) if a failure occurs, updates the 
error log. Following generation of the *txt file, a sort process 

is invoked to perform the following functions: 1) reads the 15 
Request table 390 for column(s) on which to sort the Report; 

2) reads the *.txt file; 3) sorts the *.txt file and generates two 
files: i. a file with a *.hdr extension which file contains the 
header information, consisting only of only column id's, 
and, ii. a file with a *.data extension which file contains 20 
sorted data provided in the *.txt file and is the body of the 
Report; 4) it further updates the request status table with a 
'success* or 'failure* code; and, 5) if a failure occurs, updates 
the error log. 

As further shown in FIG. 14(6), continuously running 25 
FTP, NRL and ARDA processes are provided to take appro- 
priate actions in accordance with the request status table 
entries. For example, an FTP process 378 performs the 
following functions: 1) reads the status table 391 for entries 
ready to be sent to the Inbox and FTT's the .csv or .txt to the 30 
inbox 270; 2) Determines success or failure of file transfer; 

3) Updates the Request Status table 391; and, if a failure 
occurs, updates an error log. 

The NRL (Notification of Report Location) process 382 
performs the following functions: 1) reads the Request 35 
Status table 391 for any success status or failure of any 
process; 2) Invokes a receiver process with appropriate 
status and file location populated in the NRL; and, 3) If 
failure occurs, updates the error log are text files. 
Particularly, should an error occur in any of the DSS 40 
processes, an error log is updated. Error log directories may 
be delineated by process and day of week. Each new error 
generated by the same process in the same day appends the 
log with the new message. In either event, the NRL process 
returns the NRL message to Report manager indicating the 45 
status and location of any generated files. 

As further shown in FIG. 14(6), an ARDA process 383 
reads the status table 391 for parser failures. Should the 
parser fail due to insufficient or missing data, ARDAprocess 
will return an ARDA message to the Report Manager with 50 
the appropriate error code. In particular, the types of con- 
ditions that result in error messages being sent to the report 
manager and/or local log include: i) when the request 
message received from the Report Manager can not be 
parsed due to bad data or invalid format; ii) when the SQL 55 
can not be generated due to invalid request format or 
parameters; iii) system or process failure; iv) cannot query 
database due to a database failure; etc. 

For Priced Reporting, the StarWRS report requestor func- 
tionality is invoked as described in above-referenced, 60 
co-pending U.S. patent application Ser. No. 09/159,409, 
filed Sep, 24, 1998 . Particularly, the end-to-end process 800 
from a priced report request to report delivery is shown in 
FIGS. 16(a)-16(c). Specifically, a user first establishes com- 
munication with the DMZ Web server 44 and logs on to the 65 
nMCI Interact system by entering the user's name and 
password onto a logon dialog box. Then, an application 
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running on the backplane directs a "Validate User Message" 
common object to the StarOE server 280 via the web server 
and dispatcher servers (FIG. 3) to direct the StarOE server 
280 to perform security validation and authenticate the user 
ID and password in the manner as described in commonly 
owned, co-pending U.S. patent application Ser. No. 09/159, 
514, filed Sep. 24, 1998 , entitled AUTHENTICATION 
AND ENTITLEMENT OF WEB BASED DATA MAN- 
AGEMENT PROGRAMS, the contents and disclosure of 
which is incorporated by reference herein. It is understood 
that all communication to the StarOE server is via TCP/IP 
with a Unix process listening on a known TCP port. The 
StarOE server acts as a proxy when messages are sent from 
the Dispatcher server 46 and supports synchronous transac- 
tions. All data and security information is accessed by direct 
queries to a StarOE server database 283, such as provided by 
Informix. Once a user is logged on, the Web Server 44 
(FIGS. 3 and 12) requests a current list of authorized 
applications from the StarOE server 285. Particularly, as 
described in co-pending U.S. patent application Ser. No. 
09/159,408, filed Sep. 24, 1998, the contents and disclosure 
of which is incorporated by reference herein, a "Get User 
Application Request" message is communicated to the 
StarOE server via the backplane from the report requester 
which queries the Informix database to obtain a list of 
authorized applications, i.e., services, for the user and which 
determines which buttons on the home page are active, thus 
controlling their access to products. This information is 
downloaded by a GUI applet that is executed via the 
Backplane (FIG. 4) and incorporated into the home page that 
is presented to the user. An exemplary home page screen 
display 80 is shown in FIG. 5 which provides a list of icons 
70 representing the possible options available to the user 
according to that customer's entitlements. 

Appendix H of co-pending U.S. patent application Ser. 
No. 09/159,409, filed Sep. 24, 1998 provides the format and 
content of the nMCI Interact common objects downloaded 
to the Report Requestor client application to enable web- 
based reporting. As shown in above-referenced Appendix H, 
the Report Requestor first asks for common objects for a 
user's default timezone, language and currency. The Report 
Requestor objects are invoked to retrieve from StarOE the 
various customer entitlements relating to security, geo- 
graphical hierarchy, billing hierarchy, and paging and e-mail 
notification, as further shown in Appendix H. 

In response to selection of the Report Requestor icon, a 
display is generated to present the reporting options to a user 
in accordance with that user's entitlements as previously 
determined. It should be understood that in the preferred 
embodiment, the icons for applications the user has security 
access to are shown botded. Thus, for a customer subscrib- 
ing to nMCI Interact Priced Reporting, a Priced Reporting 
icon is automatically enabled when the home page appears. 

Thus, upon selection of a Report Requestor icon 76 from 
the home page screen display 80 of FIG. 5, a StarWRS 
report requestor web page is presented to the customer. The 
backplane object allows the user access to the Report 
Requestor front end if the user is so authorized, and a client 
priced reporting application is downloaded to the customer 
who is presented with the Priced reporting dialog screen (not 
shown), as indicated at step 802 in FIG. 16(a). It is from this 
screen that the user is presented with priced reporting 
options to view/retrieve completed reports via the StarWRS 
Inbox, or create a new report or, modify an existing Priced 
call detail data report. 

Particularly, from the Priced reporting dialog screen, the 
user is enabled to edit an existing report maintained in the 
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report manager inventory, generate a new report, copy an 
existing report, or delete an existing report. For example, as 
indicated at step 805 (FIG. 16(a)), a user may initiate 
retrieval of the user report list containing existing user 
reports from the RM inventory, which process entails invok- 
ing the Report Requestor to initiate generation of a metadata 
request to download the report inventory from RM as 
indicated at step 810. The Report inventory for the specific 
user is loaded and displayed for the user on the user report 
request display screen, enabling the user to select a report, 
as indicated at step 812. Then, at step 815, the selected report 
is retrieved from StarWRS Report Manager and displayed 
for the customer. 

Then, as indicated at steps 818 and 820, the customer may 
enter the desired reporting options and reporting criteria 
including: 1) the report product including toll-free, MCI 
Vision, and MCI Vnet options; 2) the report category which 
includes options for: analyzing traffic, call center, call detail, 
checking calling frequencies, financial, marketing, monitor- 
ing usage, and telecommunications categories for toll-free, 
Vnet and Vision customers; 3) the report type which 
includes priced call detail data or traffic data options; and 4) 
a report direction and which includes inbound, outbound, or 
both directions. Additionally, the user may select the report 
format associated with a reporting category. 

Whether creating a new report or editing an existing 
report, the user is enabled to select customization options 
from successive dialog screens (not shown) that are pre- 
sented to the user showing all the report customization 
categories for building a new report and/or editing an 
existing report. From this screen and related report building 
dialog boxes, all of the initial values for retrieving the 
MetaData, customization options and GUI builder options 
from the report manager server 250 necessary to build (edit) 
a report are provided in accordance with the user's entitle- 
ments. As described in greater detail in co-pending U.S. 
patent application Ser. No. 09/159,409, filed Sep. 24, 1998, 
a user may provide the following customization and report 
builder options: general customization options; layout cus- 
tomization options; access customization options; hierarchy 
customization options; geographic customization options; 
and, notification customization options. 

In performing the report request process, as shown in FIG. 
12, the Report Requestor client application 212 gains access 
to the Metadata stored at the Report Manager server 250 
through messaging, as indicated at step 825. Particularly, as 
hereinafter described, a message generated by the Report 
Requestor in accordance with the user request is first 
received by the report manager proxy 250'. In the preferred 
embodiment, the report manager proxy comprises a set of 
tools in the form of reusable objects, preferably written in 
C++ code, or the like. For example, a parser object tool is 
employed to decompose the Metadata messages sent by the 
report requestor 212 to validate the message. If errors are 
found in the Metadata input, the RM will return an error 
message to the requesting client. If the Metadata passes the 
validation tests, the request type is then determined and the 
appropriate service will be invoked after which a standard 
response is sent back to the requesting client or and/or 
fulfilling server. 

The Report Manager 250 implements stored procedures to 
translate the message, perform the request, and send the 
information back to the Report Requestor 212 which uses 
the metadata to determine what a standard report should 
look like, the customization options the user has, and the 
types of screens that should be used for the various options 
(i.e., single selection, multiple selections, etc.). It is under- 
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stood that the selection of available standard template 
reports is based on the user's entitlements. 

The following list provides the types of requests that may 
be initiated by the Report Requestor 212 and the responses 

5 performed by the Report Manager 250: 1) Get/Send report 
template list (GRTL/SRTL) — which request retrieves the list 
of all standard report templates for all products and is used 
only to obtain general report information, e.g., report title, 
description, etc.; 2) Get/Send report template detail (GRTD/ 
SRTD) — which request retrieves the details of a specific 
standard report template; 3) Get/Send user report list 
(GURL/SURL) — which request retrieves the list of all user 
reports for the report format selected from a user report table 
and is used only as a request for general report information, 
e.g., report title, status, etc.; 4) Get/Send user report detail 

15 (GURD/SURD) — which request retrieves the details of a 
specific user's report; 5) Add report definition/ 
Acknowledgment (ARD/ARDA) — which requests addition 
of a user-created report to a user report table. If the report is 
a scheduled report, this request is also communicated to the 

20 fulfilling server at the time the report is due; 6) Delete report 
definition/Acknowledgment (DRD/DRDA) — which request 
deletes a user-created report from the user table; 7) Copy 
report definition/Acknowledgment (CRD/CRDA)— -which 
request creates a duplication of the report the user is editing 

25 (other than the report title) and creates a new report ID for 
it; 8) Update Reporting Schedule/Acknowledgment (URS/ 
URSA)— which request updates the scheduling information 
on a report without having to send a Delete and Add request; 
and, 9) Get Pick List/Acknowledgment (GPL/GPLA) — 

30 which request enables the Report Requestor 212 to get a pick 
list provided by StarOE server. 

In a preferred embodiment, as shown in Table 1, the 
interface message sent to the RM server 250 from the report 
requester via the Dispatcher server 46 comprises a three to 

35 four character message acronym followed by request spe- 
cific parameters. 



TABLE 1 



Parameter 


Parameter 




Acceptable 


Name 


type 


Required 


Value 


Request 


3 or 4 


Yes 


Msg acronym 




Characters 






Data 


Characters 


No 




parms . . . 









Table 2 illustrates the interface message format returned 
by the RM server 250. 



TABLE 2 



Parameter 


Parameter 




Acceptable 


Name 


Type 


Required 


Value 


Response 


Char (4) 


Yes 


Msg acronym 


Error Code 


Char (4) 


Yes 


0 = OK or 








error 


Data 


Char # 


No 




parms . . . 









As shown in Table 2, the response message to be returned c. 

60 in Metadata format preferably includes a four character 
message acronym followed by an error code. A successful 
request (or a request acknowledgment) generates a response 
with an error code of "0". Additional data specific to the 
response follows this error code. If any server receives a 

65 message which is not known, the response message will 
echo the message acronym back along with an appropriate 
error code. 
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Appendix A provides a series of tables containing the 
content for each metadata message request that can be sent 
by the report requestor 212 for each of the enumerated user 
requests, in addition to the content of the corresponding 
metadata message responses by the RM server 250. As an 
example, when a user requests a list of all standard report 
templates that can be created for a specified product, 
category, and product type, e.g., toll free unpriced data, an 
example metadata format is as follows: 



GRTL<PRODUCT=y DATArYPE=R,DArACAr=PJO=0> 
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esql wrapper function after obtaining the necessary infor- 
mation through the stored procedure from the Report Man- 
ager Informix database. The Report Manager creates the 
RMServerSocket object and sends the SRTL message back 

5 to the client. 

To retrieve details of the standard report template, the 
GRTD request message request is sent having content shown 
in the table in Appendix A. When specified, the Report ID 

10 field indicates an existing report that a user may wish to edit. 
The SRTD response generated by the RM server is 
formatted in metadata as follows: 



where GRTL is the message name, the PRODUCT indicates 
the product type, e.g., V-Vnet, C=CVNS, S= Vision, T-toll 
free, F-Traffic view, etc. DATATYPE indicates the data 
type, e.g. R-reports, D-call detail, etc., and DATACAT 
represents the report category, e.g., P-priced, U-unpriced. 

In the hereinafter described manner, the GRTL message is 
received by the StarWRS proxy server application 250' to 
enable the RM server 250 to perform the query into the RM 
Informix database having the data associated with the 
request. Specifically, after selecting the Report Requester 
from the browser or the Toolbar, a WRSApp object is 
launched. At its creation, the WRSApp object creates a 
DataManager object to guide the data and which initiates a 
CommunicationM anager object to manage all communica- 
tion between the client and the server. The Communication- 
Manager utilizes a RptManagerMsg object to create: 1) a 
GRTL; 2) a WRS Com m Wrapper for direct communication 
with the backend; and, 3) a WRSReportManagerUtilParser 
to format the data returned. In response, the Report Manager 
creates a Dispatcher object, which contains the business 
logic for handling metadata messages at the back-end and 
utilizes the services of a RMParser class. Upon determining 
that the client has sent a valid message, the appropriate 
member function is invoked to service the request. Upon 
receiving the message, the Report Manager creates the 
Parser object (RMParser) which takes the message apart and 
invokes a validation object which validates the message. 

In response to the GRTL message, the data returned by the 
Report Manager server 250 for this particular request may 
include the following data in metadata format as follows: 



SKTL<ERROR-0, REPORTS - <RptCategoryDescriptionl 
=<RptTitlel.l, RptTemplateIDl.1, RptCategor/Typcl.l^ 
<RptTitlel.2, RptTemplateID1.2, RptCategoryTypel.2» > 
<RptCategoryDescription2 -<RptTitle2.1, 
RptTemplateID2.1, RptCategoryType2.1>, <Rpflitle2.2, 
RptTemplatelDS^ RptCategoryType2.2», . . . 
<RptCategoryDescrip tion#n-<RptTile#a. n, 
RptTcmplatelEMto-n, RptCategoiyTypc#n.n>, <RptTitle#n.n, 
RptTemplateID#n.n ) RptCategoiyType#n.D>» 



wherein RptID# indicates a standard report template ID, 
RptTitle# indicates the standard report template title, Rpt- 
Category# indicates the report category, e.g. Monitor Usage, 
Analysis Traffic, Historical, Executive Summary, Call 
Detail, etc.; and, RptDescript indicates the standard report 
template description displayed to the user. Thus, for each 
Report Template Category, there will be the list of reports 
with each entry containing a Report Template Title, a Report 
Template Description and the Report Template ID. 

The SRTL message is sent from the StarWRS RM proxy 
server to the report requestor for presentation to the cus- 
tomer. Specifically, the SRTL response is built inside the 



< Report Template ID=[D#, 

NODEl=<node level 1, label valuel, assigned unique screen 
identification!, >, 

NODE2=<node levei2, label valuc2, assigned unique screen 
Ldenlificalion2 3 <control [D2.1, field value2.1, data 
20 location2.1>, <control ID2.2, field value2.2, data 

Iocation2.2>, <..,„,..», 

NODE#n<node level#n, label value#n, assigned unique 
screen identification^, <control ID#n.l, field 
value#n.l, data location^n-l^ <control ID#n.2, field 
value#n.2, data location#n.2» 
25 

In the SRTD message, the MetaTreeData Label fields 
include such values as General, Report Name, Report 
Description, Scheduled Execution, etc. The MetaCtrllnfo 

30 MetaField Value fields may be blank or may contain the 
selection options available to the user. This information is 
taken from the report template database. 
As another example, when a report request is submitted to 

3S retrieve a full list of user created reports from a user report 
table, i.e., a template list for a particular report product, 
category, and type, the example metadata format is as 
follows: 

40 

GURUUSERID-jearlvnet2,RPTTMP^I>.l,E^OTID^(X)22924, 
PRODUCT-T,DATACAT-U> 



4 5 with UserlD and ReportTemplatelD fields specified. 
Specifically, this process entails invoking the Communica- 
tion Manager object to communicate with the RM server in 
order to obtain a SURL metadata message. The Communi- 
cationManager utilizes the RptManagerMsg object to create: 

50 1) a GURL, 2) a WRSCommWrapper for direct communi- 
cation with the backend, and, 3) a WRSReportManagerUtil- 
Parser to format the data returned. The parser returns a hash 
table containing the User Report List. At the RM server, the 
Report Manager creates an Dispatcher object that contains 

55 the business logic for handling metadata messages at the 
back-end and utilizes the services of the RMParser class. 
Upon determining that the client has sent a valid message, 
the appropriate member function is invoked to service the 
request. The Report Manager, upon receiving a message, 

60 creates a Parser object (RMParser) which takes the message 
apart and invokes a validation object which validates the 
message. 

In response to the GURL request, the data returned is 
65 taken from a user report table in the RM server database. The 
generic SURL message in Metadata format returned by the 
RM server 250 includes the following information: 
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40 



REPORTS - <UserRptGnegoryl = <UserRptTItlcl > 
UserRptlDl, activeflag, report type, statusdate », 
<UserRptCategory2 - <UserRpOitle2, UserRpttD2, 
activeflag, report type, statusdate», . . . 
<UserRptCategory#n = ^UserRpttilletfn, UserRpUTMta, 
activcflag, report type! statusdate»> 



wherein for each user report category, there is a list of 
reports where each entry contains a UserRptID# indicating 
a user-defined report template ID, a UserRptTitletf indicat- 
ing the user's report template title, and a UserRptCategory# 
indicating the user report category. Specifically, the SURL 
response is built inside an esql wrapper function after 
obtaining the necessary information through a stored pro- 
cedure from the Informix database. The Report Manager 
creates the RMServerSocket object and sends the SURL 
message back to the client. 

To retrieve the details of a specific user's report, the 
GURD message is sent having data as contained in the table 
shown in Appendix A. Specifically, when the user selects a 
report from the Inventory List on the Report Requestor, a 
Communication Manager object is invoked to communicate 
with the RM server in order to obtain a SURD metadata 
message. The CommunicationManager object first utilizes 
the RptManagerMsg object to create: 1) a GURD metadata 
message, 2) a WRSCommWrapper for direct communica- 
tion with the backend, and 3) the RSReportManagerUtil- 
Parser to format the data returned. The parser organizes the 
data into a series of nodes which are utilized to create the 
report builder tree on the report requester customization 
screen. Later this data will be extracted from the node and 



< Report Template ID=[D#, 

NODEl=<node level 1, label valuel, assigned unique screen 
5 identification 1, >, 

NODE2=<node level2, label value2, assigned unique screen 
identification2, <control ID2.1, field value2.1, data 
location2.1>, <control ID2.2, field value2.2, data 
location2.2>, <..,.. ,..;», 

NODE#n=<node level#n, label value#n, assigned unique 
10 screen identification^, <control ID#n.l, field 

valuc#n.l, data location#n.l>, -ccontrol ID#n.2, field 
value#n.2, data location#n.2> > <..,..,..», 



This response thus may include the report information 
15 having detailed items including: UserReportID (UserlD), 
User's report name (UserName), product (UserProd), 
Threshold (UserThreshold), User Report Description 
(UserDescript), Report Columns (UserFields), Report col- 
2Q umn headings (UserHeaders), and, in addition, customiza- 
tion options with fields indicating, inter alia, columns to 
display (UserHeaders), user-defined criteria (UserCriteria), 
a sort order (UserOrder) and scheduling selections 
(UserSched), the last update of this report (UserLastUpdate) 
25 and, the Report status (if adhoc) (UserStatus), etc. 

If a request is made to add a user-created report to a 
User__report table maintained by the RM Server 250 and the 
RS server 260, the ARD metadata message having fields 
defined in the table provided in Appendix A is processed by 
30 the RM server 250, as indicated at step 828, FIG. 16(a). An 
example message in metadata format to initiate the addition 
of a user-created report for ODS (Inbound/Outbound) 
reporting data is as follows: 



ARD<USERID=jeanvnet2^NTPID=00022924 7 STDRPTIDo90,NAME=Ci 
ty Summary Outbouad,PRODUCT-S,CAreGORY-Analyze Traffic, 
THRESHOLI><RECCOUNT=20>,SCHEDULE=A^START=199806020000 > EN 
D= 1998071 5 1200>,RANGETYPE=l^CHEiyi^PE=A,TIMEZON T E=45,B ELL 
[NG-I^roOlJND<<9(W00ra3,90ro0003><^^ 

0000004^0000004>cNA^rAxNA ) NA»,CARDNO=<654654*-5465465 

465465465>,IDAC=<46546546*~1246>,GEO=GEO«001 > 001 

USA/WORLDZONElxNA,NA><NA^JAxNA > NA><NA^A»GEO«001,001 

USA/WORLDZONEl><CO,CO><NA,NA><NA^A><NA,NA»,OACCESS=<4~ 

l>,ODISTRANGE=<A~F> J OUSAGE«<5-4> J SORTBY=<54D> > DESCRIPTIO 

N=This report summarizes call detail by the terminating 

city and state (USA) / province (CA). The report is 

based on the date/time ranges and report criteria 

selectcd.,COLUMNS-<54~55~67~62~36~61~5a~6S~64^6^5>^\Cr 

rVE-a,TOTALMODE-0 J EMAIL-0^AGE-0, LANG-1234, CURR-2345> 



used to construct the screen related to the node. The Report 
Manager server creates the MCIDispatcher object which 
contains the business logic for handling metadata messages 
at the back-end and utilizes the services of the RMParser 
class. Upon determining that the client has sent a valid 
message, the appropriate member function is invoked to 
service the request. The Report Manager, upon receiving a 
message, creates the Parser object (RMParser) which takes 
the message apart, invokes a validation object which vali- 
dates the message and builds a response inside the esql 
wrapper function after obtaining the necessary information 
through the stored procedure from the Informix database. 
The Report Manager creates the RMServerSocket object and 
sends the SURD/SRTD message back to the client. The 
responsive SURD metadata message corresponding to a 
retrieve user report detail (GURD) request has the following 
metadata syntax: 



In this example, the "NAME" field refers to the Report 
Name (e.g., city summary); the "PRODUCT" field refers to 
the report product (Vision); the "THRESHOLD" field refers 
to the record count; the "DESCRIPTION" field refers to the 

55 report description; the "COLUMNS'* refers to the number of 
columns specified for a report by the user; the "BILLING" 
field refers to the specified report billing entitlement, i.e., 
billing hierarchy; the "IACCESS" field refers to the inbound 
access type and the "OACCESS" refers to the outbound 

60 access; the "SORTBY" field indicates the report column 
sorting customization with "A" indicating column(s) having 
data to be sorted in ascending order and, "D" indicating 
cotumn(s) having data to be sorted in descending order; the 
"SCHEDULE" field referring to the scheduling type, e.g., 

65 with "A" indicating an ad-hoc report, and the user specified 
date range on which to report as indicated by the "START* 
and "END" fields, and additionally, the scheduling fre- 
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quency information in the case of a recurring report; the cedure from the RM database. The Report Manager creates 

SUBTOTALCOLUMNS field, referring to the report col- the RMServerSocket object and sends the ARDA message 

umns having data to be subtotaled; and, the "EMAIL" and back to the client. 

"PAGE" fields indicating reporting notification via e-mail or As illustrated in FIG. 16(a), at step 830, in reference to 

paging, respectively. 5 user selection of a Save and Run report option, the report is 

Furthermore, for each of the metadata messages in Appen- marked as scheduled and saved in a user_table in the Report 

dix A, including the Delete Report Definition (DRD), copy Scheduler server 260 via the Report Manager. Subsequently, 

report definition (CRD), and update report scheduling as indicated at step 630, the Report Scheduler server 260 

(URS) messages, the report manager server 250 responds to generates an ARD message (Appendix D) and sends the 

the Report Requestor with the processing results. In the case to ARD message to StarODS DSS server for which the DSS 

of a copy report, a new User Report ID is assigned and has a predefined interface, as described herein, 

returned by RM. When editing an existing StarODS (priced Next, as indicated at step 832, the DSS receives the 

call data) report, the user may make changes to the Report request and acknowledges receipt. Specifically, when the 

Title, the Report Description, the Report scheduling, the 800 request is received it is first validated with StarOE to ensure 

numbers and thresholds, and may customize number of 15 that the user is entitled to receive information about the 

rows, report columns, access codes, access types, billing selected product corp and numbers). Once the request 

location, geographic location, paging notification, and passes validation, the DSS IAIO reads the header to deter- 

e-mail notification. More specifically, when the user selects mine which Data Mart will ultimately be queried. It then 

a report from the inventory list or a new report, an WRSEdit parses the metadata into a format which the COTS software 

Screen is launched to provide the editing capabilities which 20 can readily convert into a SQL statement, as indicated at step 

are available for the report format. WRSedit guides the 835, FIG. 16(Z>), and adds the report to the DSS report queue 

screens through the process of retrieving the screens' data. based upon type (Daily, Weekly, Monthly, Adhoc) and 

Some of the screens need data which has not yet been . associated DataMart, as indicated at step 638. It should be 

retrieved, such as 800 numbers or geographic locations. understood that at this point, the request has been flagged as 

Tnese screens manage the requests to the DataManager 25 submitted in the RM database, as indicated at step 633. 

object to create the get pick list (GPL) message (Appendix From this point forward, DSS activity is controlled by a 

A), which launches the CommunicationManager object to control process and progress or errors are logged internally 

perform this task. The CommunicationManager utilizes the in the DSS system. This control process includes logic 

RptManagerMsg object to create the GPL, the WRSCom- enabling the prioritization of report requests and application 

mWrapper for direct communication with the backend, and 30 of rules defining the order in which they should be executed, 

the WRSReportManagerUtilParser to format the data Thus, at the appropriate time, depending on the type or 

returned. In response, the Report Manager server creates the report, reporting period and other parameters, the Informa- 

MCIDispatcher object and invokes the MCIRMParser class. tion Advantage query engine selects the report from the 

Upon determining that the client has sent a valid message, queue, as indicated at step 840, which action is logged in the 

the appropriate member function is invoked to service the 35 report status table (Appendix J) as indicated at step 842. The 

request. The Report Manager, upon receiving a message, SQL statement is then built by Decision Suite™ and routed 

creates the Parser object (RMParser) which takes the mes- to the appropriate data mart for execution in the manner as 

sage apart and a validation object is invoked which validates described herein, as indicated at step 843. The query engine 

the message. The response is built inside the esql wrapper generates the SQL statement from the metadata and executes 

function after obtaining the necessary information through 40 the report which action is logged in the report status table as 

the stored procedure from the Informix database. The Report indicated at step 845. Next, as indicated at step 848, the 

Manager creates the RMServerSocket object and sends the query results are returned, and, a post-SQL formatting 

GPLA message back to the client. process is invoked. 

Having described the functionality of selecting and/or More particularly, as shown in FIG. 15(£>), a Formatter 

generating a report and customizing it, reference is now had 45 module 395 may perform various report result transforma- 

to the process for running the report request in StarODS. tions including: 1) Converting of column headers generated 

Particularly, in the preferred embodiment, the user may by Information Advantages into appropriate column ids that 

select a save and exit report option, or a save and run report are recognizable to the StarWRS client viewer functionality 

option. In either scenario, an WRSEdit object enables a (as indicated at step 850, FIG. 16(b)); 2) Provide subtotaling 

WRSScnMgr object to save the report to the RM server. The so for specific requested "subtotal by^' columns in the format 

WRSScnMgr object launches each screens save method required by the StarWRS client interface (as indicated at 

which communicates with the DataManager object to place step 853, (FIG. 16(b)) and provides report-based totals as 

the screens data in its corresponding WRSNode. Once all of requested by customer; 3) converting binary stream data file 

the WRSNode objects have been updated, the WRSScnMgr to ASCII text file (as indicated at step 855, FIG. 16(c)); 4) 

object calls the DataManager object's SaveReport method to 55 implementing Replace logic, e.g., replacement of "TAB" 

build a hash table to contain all of the report's data. The delimiters with appropriate "Comma 5 ' field delimiters (as 

CommunicationManager utilizes the RptManagerMsg indicated at step 857 FIG. 16(c)); 5) implementing Repeat/ 

object to create the ARD metadata message from the hash Padding logic, i.e., identifying compressed columns/values 

table, the WRSCommWrapper for direct communication and decompressing (or repeating) the values that were 

with the backend, and the WRSReportManagerUtilParser to 60 compressed; 6) providing alphanumeric translations for any 

handle any errors thrown by the server. The Report Manager encoded data elements returned in the result set data file (as 

creates the Dispatcher object, and utilizes the services of the indicated at step 859, FIG. 16(c)); and, 7) adding new 

RMParser class and validation objects. Upon determining computed/derived columns, e.g., percents, averages of col- 

that the client has sent a valid message, the appropriate umn data values, etc., as requested by customers on specific 

member function is invoked to service the request. The 65 reports. 

response is built inside the esql wrapper function after Particularly, as shown in FIG. 15(b), the Formatter pro- 
obtaining the necessary information through the stored pro- cess 395 reads the *.hdr files and *.data files from the 
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Decision Suite™ result set to obtain respective column 
names and report data. Particularly, the formatter process for 
converting Column Headers from Information Advantage® 
column header names to column ids implements a lookup of 
column ids in a column_id's table, shown in Appendix J, 
based on column header names. 

Then, the formatter process reads the request table 390 for 
total/subtotal, threshold, etc. information associated with the 
current report request and determines any other formatting 
features to be enabled for a particular result set. As shown 
in the example Request Table of Appendix J, parameters 
passed to the formatter module indicate any report request 
specific details that are required by the Formatter. For 
example, for report totals, a "total-mode" variable is used to 
indicate if report totals and/or sub-totals should be included. 
Particularly, Column IDs representing the data columns 
upon which subtotaling is based are passed as parameters to 
the Formatter process 395 and are referred to as "Break 
Columns". At appropriate changes in values for these break 
columns, the formatter generates a subtotal line for subto- 
taling the applicable additive facts including, for example, 
Call Amount, Call Duration, and Call Count. 

Furthermore, the formatter reads a Column id table 396 
(detailed in Appendix J) to determine data types and if any 
data translations are needed. 

As computed/derived columns may be included or 
excluded from customer report requests, the Formatter pro- 
cess 395 for calculating new computed/derived columns on 
specific customer-requested reports are provided on a report 
request basis. Example types of derived columns include: 1) 
Percents, e.g., based on the additive data facts pertinent to 
the report request and are typically based on report totals and 
row amounts for Call Amount, Call duration, and Call 
Count; 2) Row-wise derived data elements as requested, 
which represent data elements computed based on original 
additive data elements on a row by row basis (i.e., column 
x/column y for each row in the result data file) and typically 
include average calculations such as Average # of Minutes 
per Call, Average Amount per Call, and Average Amount per 
Minute. Appendix J illustrates a derived column "percent" 
calculation indicated in the Column ID table showing an 
equation for calculating a value of a particular value (C36) 
divided by a column total (CT36)xlOO. 

The Formatter process 395 may additionally perform 
alphanumeric translations for any encoded data elements 
returned in the result set data file by implementing appro- 
priate lookup in a Translation table 397, such as the example 
Translation Table provided in Appendix J, and replacing the 
code. 

Referring back to FIG. 16(c), after formatting the report, 
as indicated at step 860, a message is sent to the control 
process to update the request status table 391. It should be 
understood that, if a failure occurs during formatting, the 
error log is updated and a status message sent to the request 
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status table 391, as well. Then, as indicated at step 865 (FIG. 
16(c)), the formatter 395 creates a * .csv (Comma Separated 
Value) or .txt file, gives the file a unique name and saves the 
file. Preferably, a *.csv is the file generated if the report is 

5 successfully generated. 

As indicated at step 868, the *.csv report/data file is then 
"pushed", implementing FTP, to the StarODS server's direc- 
tory on the Inbox server 270. The StarODS server 400 is 
responsible for generating unique file names within their 

1Q directory on the Inbox server 270. For example, the follow- 
ing directory and file naming conventions used for reports 
generated by the StarODS server are labeled inbox\files\ods 
with text files having the suffix *.txt or *.txt zip 
(compressed), and comma separated files having a suffix 

15 *.csv or *.csv_zip (compressed). 

Finally, as indicated at step 870, once the file has been 
successfully transferred to the Priced reporting directory on 
the Inbox server, and the request status table 391 appropri- 
ately updated at step 875, the NRL process (FIG. 14(b)) 

20 generates and transmits an NRL message to the RM Server 
250 notifying it of the report file name and location in the 
Inbox, requester information, and if the transfer was suc- 
cessful. This is accomplished by using a "NRL" metadata 
message. 

25 Appendix B provides a table comprising the Notify 
Report Location parameters used for the NRL Metadata 
messaging sent by StarODS fulfilling server to the RM 
Server 250 when a requested report is complete. An example 
NRL message sent from the ODS server 400 to the RM 

-„ server 250 is as follows: 



^^<TYPE^im-Msg-40,E^r^PII>>00022924,USERID=do^od, 
STDRPTID=40,USERRPTID=3415,REOUESTID=20341,COMPRESS=0, 
35 IX>C-/inbox/mes/testODS/STDRP^D43TM_082598_084920.CSV, 
FSIZE=389,PRESORTED=0> 



An NRLA response is sent back to the DSS as shown in 
Appendix B. 

40 Once the RM server 250 has received the NRL message 
from the fulfilling server, it verifies the file's presence and 
builds a metadata file, e.g., by compressing the appropriate 
metadata (for displaying the report) into a .MTD file. This 
.MTD file is utilized by the Report Viewer to know how to 

45 display the report. The Report Manager server creates a file 
including the metadata using the same file name as the 
report/data file, but having the following suffix: *.mtd or 
*.mtd__zip indicating a metadata or compressed metadata 
file, respectively. 

so Appendix F details the parameters that are passed in the 
GET METADATA messaging for indicating to the Report 
Viewer how to display a requested report. For example, a 
GET METADATA message corresponding to an Priced TVS 
fulfilling server report is as follows: 



<METADATA-^RriERIA-<Namc-UsageSuminary292"ADescriptiott- 
This report summarizes calls based on call type. A 
Rep<»t_Uvel-<INBOU^<<9(»0W 

I^^u^ro<<900(W(»2 > 9O(X)oo02>^^ 

_Iaformation='AOne_TLme=^ACtates=.<06/01/199800:(X]/~07/01/l 

99800:00 ,>>rimczoncoEST,Lang-1234,Curr=2345>DEFAULT_GRAP 

H_MODE=0" ADEFAULT_GRAPH_TYPE=0 " ADEFINE_X_AXIS=0 

* AX_AXIS_COLUMN= ADEFAUL T_Y_COLUMNS=<> " A 

COLUMN_DISPLAY_ORDER-<105*A114"A67"A62"A36*A61 s A58"A63*A6 

4*A66 A A65>*ASORr_^ALLOWED=l*APRESORTED=0"A 
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-continued 

PRESUBTOTALED-1 'ATOTALMODE=0"ASORT_COLUMN S-<105A>"a 
SUBTOTAL_COLUMNS°<> * ASELECTED_SECnON=0*A 
METACOLUMN-<META_COLUMN_JD-105 * A 

CO LUMN_LABEL= Usage Description AD ATATYPE=S ADECIMAL=0 A 
HIDEABLE=l*AGRAPHABLE-0 AW IDTH-20 * ACALCULATE=0 " A 
CALCULATE_EXPRESSION-> * AM ETACO LUM N- <M ETA_CO LU MN_rD- 1 1 4 * A 
COLUMN_LABEL=Rangc/DistanccDc5crigtion " ADATATYPE=S " ADECIM 
AI^VHIDFJVBLE=l"AGRAPElABl£^"AWlDTH=20'AC^LaJl^TE^> 
CALCU1jOT_EXPRESSION->*AMETACOLUMN-<META_COLUMN_ID-67*A 
COLUMN_LABEL»Calls ADATATYPE=I ADECIMAL=0 AHIDEABLE^l " A 
GRAPHABLE=1 " AWIDTH=7 * ACALCULATE=0 ' ACALCULATE_EXPRESSION=> 
'AMETACOLUMN-<META_^COLUMN_ID-62"ACOLUMN_LABEL-% Calls *A 
DATATYPE=N ADECIMAL=1 AHIDEABLE=1 AGRAPHABLEM AWtDTH=7 A 

calculate«o"acalculate_expression=>"a 

METACOLUMN-<META_.COLUMN_ID-36^ACOLUMN_LABEL-MLnutcs * A 
DATATYPE-N~ADECIMAL=1 AHIDEABLE=1 AGRAPHABLE-1 AWIDTEMTa 
CALCULATED) " ACALCULATE_EXPRESSION=> * A 

METACOLUMN-<META_COLUMN_ID-6r ACOLUMN_LABEL-% Min*A 
DATATYPE=N'ADEC[MAL-1 "AHIDEABLE-l" AGRAPHABLE-1 "a 
WIDTHS *ACALCULATE=0" ACALCULATE_EXFRESSION->"A 
METACOLUMN-<META_COLUMN_ID-58 " ACOLUMN_LABEL= Amount "ADATAT 
YPE-C ADECIMAL-2 AHIDEABLE-l A 

GRAPHABLE-1 * AWIDTH=7 * ACALCULATE°0 "aCALCULATE_EXPRESSION=> 
'aMETACOLUMN-<META_COLUMN_ID-63'aCOLUMN„LABEL=% Amt"A 
DATATYPE=N*ADECIMAL=1 "ahideable-i AGRAPHABLE-1 *AWIDTH-5 *a 
CALCULATED ACALCULATE_EXPRESSI0N=> A 

METACOLUMN=<META__COLUMN_ID=64 ACOLUAlN_LABEL=Avg M in/ Call 
'ADATATYPE-N " ADECIMAL=2 * AHIDEABLE-1 AGRAFHABLE-1 * A 
WIDTH= 1 2 " ACALCULATE=0 * ACALCULATE_EXPRLSSION=> * A 
METACOLUMN=<META_COLUMN_ID=66 " ACOLUMN_LABEL=Avg 
Amt/Calf A 

DATATYPE=N A ADECIMAL=2" AfflDEABLE=l AGRAPHABLE=1 * AWIDTH-12 
*A CAlCULATEaO*ACALCULATE_EXPRESSION=>*A 

METACOLUMN-<META_COLUMN_ID-65 * ACOLUMN_LABEL-Avg Amt/Min * A 

DATATYPE=N ADECIMAL°2 AHIDEABLE^l " AGRAPHABLE=1 * A 

WIDTHS! ~ACAl^ULATE=0"ACALCULA'rE__EXPR£SSION=>>> 

* <METADATA- <CRITER1A- <Name-My Report, Total-Totals are 

located at the bottom of the report., Dcscription=My 

report description, Number_Dtaled=«800#l, S00#2, 800#n>, 

Scheduling_Information- Recurring, Dates- Monthly» 

DEFAULT_GRAPH_MODE=l, DEFAULT_GRAP H_TYPE=1 , 

DEFINE_X^AXIS=1, X__AXIS„COLUMN=2, 

DEFAULT_Y_COLUMNS-<5,6>, 

C0LUMN_DISPLAY_0RDER-<1,2 > 3,4,5,6>, 

COLUMN„STORED_ORDER=<43,2A64>, SORT_ALLOWED=l, 
PRESORTED - 1, TOTALMODE-3, SUBTOTCOL-<5,6>, SELECTED 
SECTION-1, M ETACO LUMN=<META_COLUMN_ID=l, 
COLUMN_LABEL=name, DATATYPES, DECIMAL=0, HIDEABLE=1, 
GRAPHABLE-O, WIDTH-10, CALCULATE-1, 
CALCULATE_EXPRESSION»<4 / 7»» 



Once the metadata file corresponding to the requested 
report is build by the Report Manager, the RM ftp's the 
.MTD file to the Inbox server. The RM server additionally 
updates a User_report table status field with a status "C" 
indicating completion. 

Once the Report Manager has updated the status field, the 
RM server 250 then adds the report to the user's Inbox. 

Appendix C provides a table showing the fields for the 
metadata messaging between the RM server 250 and the 
Inbox server 270 for adding an item into the StarWRS 
system Inbox server 270, and the respective acknowledg- 
ment message format back from the Inbox server. In the "A" 
message found in Appendix C, the "LOC" field includes 
information about where the report data is located. For 
example, a metadata message indicating to the Inbox server 
that a priced ODS server report is available is shown as: 



45 



A<CATEGORY=R,TYPE^traffic^QUESTtD=32197 > USERID= 
LyrmeI^vy2^PTirMl50 7 PRIORn^=COMPRESS=0,UNOTIFY= 
50 O^MADDR-jMMTEXT-jPGT-jPGPIN-jPGTXT-^PTCATEGORY- 

Servicc Location & Hour, 

LOC=/inbo^mes/ods/902512294STDRFTID10.CSV,ENTP 

ID-10324488 ) RQSTDT-1998-01-02 

15 :18 } FSIZE=3705,RPTTTTLE=Surnmary by Service 

Location and Hour,MSIZE=3322> 



Particularly, the RM server supplies a metadata "A" 
message to the Inbox indicating the FTP file location. Via the 
report viewer, the report is now available for viewing, 
downloading, saving, or printing by the user, and as 

60 described in further detail in co-pending U.S. patent appli- 
cation Sen No. 09/159,512, filed Sep. 24, 1998, entitled 
MULTI-THREADED WEB BASED IN-BOX FOR 
REPORT MANAGEMENT, the contents and disclosure of 
which are incorporated by reference as if fully set forth 

65 herein. Particularly, as shown in the exemplary nMCI home 
page in FIG. 4, the nMCI Interact Message Center icon 77 
may be selected which will cause the display of a web page 
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including the message center dialog window. From the desired service. The user's entitlements in this regard are 

message center dialog window, a user may select from fetched by the dispatch server from Order Entry server 280 

among three tabs, one of which, a reports tab, enables the at logOD time and cached. Assuming that the Requestor is 

retrieval of both a data file and a metadata file from the Inbox authorized to communicate with the target service, the 

Server corresponding to those reports that have been run and 5 message is then forwarded to the desired service's proxy, 

available for customer viewing. Information provided for which> in me accordance with the principles described 

display by the message center display 325 is provided by the hereill) comprises: 1) a report manager proxy 250' corre- 

User_table which keeps track of the status of all reports for spondin g t0 ^ RM Server 25 0, 2) a report scheduler proxy 

a particular user By double-clicking a chosen report, a 260 , ^^0^ t0 , he RS server 260, and 3) an inbox 

report viewer application is enabled to display the chosen M ^ 2W ^ adia to ^ Inbox 5^ 270 . 

report on a web-page. To view the report the user selects the r , r, , t - 

^ j *u -* *j* j*u -4 Each of these proxy processes further performs: a validation 

report and, the report metadata and the appropriate viewer - v / Y . * , n 

are uploaded to the user (client) workstation. P u roo( f for f 3 f nm f?« ^ confirming 

As mentioned herein with respect to FIG. 3, the messages * at the y include vahdl y ^matted messages for the service 

created by the client Java software are transmitted to the ^ acceptable parameters; a translation process for trans- 

StarWeb (DMZ) Server 44 over HTTPS. For incoming 15 latin S a message into an underlying message or networking 

(client-to-server) communications, the DMZWeb servers 44 protocol; and, a management process for managing the 

decrypt a request, authenticate and verify the session infor- communication of the specific customer request with the 

mation. The logical message format from the client to the middle-tier server to actually get the request serviced. Data 

Web server is shown as follows: returned from the middle-tier server is translated back to 

20 client format, if necessary, and returned to the dispatch 

server as a response to the request. 

FIGS, 18(a) and 18(£>) are schematic illustrations showing 

|| TCP/IP || encryption || http || web header f| the message format passed between the Dispatcher 46 and 

dispatcher header || proxy-specific data j| ^ application proxy 18(fl) ) ^ me meS sage 

25 format passed between the application specific proxy back to 
where "||" separates a logical protocol level, and protocols the Dispatcher 46 (FIG. 18(6)). As shown in FIG. 18(a), all 
nested from left to right. FIG. 17 illustrates a specific messages between the Dispatcher and the Proxies, in both 
message sent from the client browser to the desired middle directions, begin with a common header 110 to allow 
tier server for the particular application. As shown in FIG. leverage of common code for processing the messages. A 
17, the client message 340 includes an SSL encryption 30 first portion of the header includes the protocol version 115 
header 342 and a network-level protocol HTTP/POST which may comprise a byte of data for identifying version 
header 344 which are decrypted by the DMZ StarWeb control for the protocol, i.e., the message format itself, and 
Server(s) 44 to access the underlying message; a DMZ Web is intended to prevent undesired mismatches in versions of 
header 346 which is used to generate a cookie 341 and the dispatcher and proxies. The next portion includes the 
transaction type identifier 343 for managing the client/server 35 message length 120 which, preferably, is a 32-bit integer 
session; a dispatcher header 345 which includes the target providing the total length of the message including all 
proxy identifier 350 associated with the particular type of headers. Next is the echo/ping flag portion 122 that is 
transaction requested; proxy specific data 355 including the intended to support a connectivity test for the dispatcher- 
application specific metadata utilized by the target proxy to proxy connection. For example, when this flag is non-zero, 
form the particular messages for the particular middle tier 40 the proxy immediately replies with an echo of the supplied 
server providing a service; and, the network-level HTTP/ header. There should be no attempt to connect to processes 
POST trailer 361 and encryption trailer 366 which are also outside the proxy, e.g. the back-end application services, 
decrypted by the DMZ Web server layer 44. The next portion indicates the Session key 125 which is the 

After establishing that the request has come from a valid unique session key or "cookie" provided by the Web 
user and mapping the request to its associated session, the 45 browser and used to uniquely identify the session at the 
request is then forwarded through the firewall 556 over a browser. As described above, since the communications 
socket connection 33 to one or more decode/dispatch servers middleware is capable of supporting four types of transport 
46 located within the corporate Intranet 60. The messaging mechanisms, the next portion of the common protocol 
sent to the Dispatcher will include the user identifier and header indicates the message type/mechanism 130 which 
session information, the target proxy identifier, and the 50 may be one of four values indicating one of the following 
proxy specific data. The decode/dispatch server 46 authen- four message mechanisms and types: 1) Synchronous 
ticates the user's access to the desired middle-tier service. transaction, e.g., a binary 0; 2) Asynchronous request, e.g., 

As shown in FIG. 17, the StarWeb server forwards the a binary 1; 3) Asynchronous poll/reply, e.g., a binary 2; 4) 
Dispatcher header and proxy-specific data to the Dispatcher, bulk transfer, e.g., a binary 3. 

"enriched" with the identity of the user (and any other 55 Additionally, the common protocol header section 
session- related information) as provided by the session includes an indication of dispatcher-assigned serial number 
data/cookie mapping, the target proxy identifier and the 135 that is unique across all dispatcher processes and needs 
proxy-specific data. The dispatch server 46 receives the to be coordinated across processes (like the Web cookie (see 
requests forwarded by the Web servers) 44 and dispatches above)), and, further, is used to allow for failover and 
them to the appropriate application server proxies. 60 process migration and enable multiplexing control between 
Particularly, as explained generally above with respect to the proxies and dispatcher, if desired. A field 140 indicates 
FIG. 12, the dispatch server 46 receives request messages the status is unused in the request header but is used in the 
forwarded by the DMZ Web servers and dispatches them to response header to indicate the success or failure of the 
the appropriate server proxies. The message wrappers are requested transaction. More complete error data will be 
examined, revealing the user and the target middle-tier 65 included in the specific error message returned. The status 
service for the request. A first-level validation is performed, field 140 is included to maintain consistency between 
making sure that the user is entitled to communicate with the requests and replies. As shown in FIG. 18(a), the proxy 
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specific messages 375 are the metadata message requests 
from the report requester client and can be transmitted via 
synchronous, asynchronous or bulk transfer mechanisms. 
Likewise, the proxy specific responses are metadata 
response messages 380 again, capable of being transmitted 
via a synch, asynch or bulk transfer transport mechanism. 

It should be understood that the application server proxies 
can either reside on the dispatch server 46 itself, or, 
preferably, can be resident on the middle-tier application 
server, i.e., the dispatcher front end code can locate proxies 
resident on other servers. 

As mentioned, the proxy validation process includes 
parsing incoming requests, analyzing them, and confirming 
that they include validly formatted messages for the service 
with acceptable parameters. If necessary, the message is 
translated into an underlying message or networking proto- 
col. A list of Report Manager and Inbox proxy error mes- 
sages can be found in Appendix E. If no errors are found, the 
proxy then manages the communication with the middle-tier 
server to actually get the request serviced. The application 
proxy supports application specific translation and commu- 
nication with the back-end application server for both the 
Web Server (java applet originated) messages and applica- 
tion server messages. 

Particularly, in performing the verification, translation 
and communication functions, the Report Manager server, 
the Report Scheduler server and Inbox server proxies each 
employ front end proxy C++ objects and components. For 
instance, a utils.c program and a C++ components library, is 
provided for implementing general functions/objects. Vari- 
ous C++ parser objects are invoked which are part of an 
object class used as a repository for the RM metadata and 
parses the string it receives. The class has a build member 
function which reads the string which contains the data to 
store. After a message is received, the parser object is 
created in the RMDispatcher.c object which is file contain- 
ing the business logic for handling metadata messages at the 
back-end. It uses the services of an RMParser class. Upon 
determining that the client has sent a valid message, the 
appropriate member function is invoked to service the 
request. Invocation occurs in MCIRMServerSocket.C when 
an incoming message is received and is determined not to be 
a talarian message. RMSErverSocketc is a class implement- 
ing the message management feature in the Report Manager 
server Public inheritance is from MClServerSocket in order 
to create a specific instance of this object. This object is 
created in the main loop and is called when a message needs 
to be sent and received; a Socket.c class implementing client 
type sockets under Unix using, e.g., TCP/IP or TCP/UDP. 
Socket.C is inherited by ClientSocket.C:: Socket 
(theSocketType, thePortNum) and ServerSocket.C:: Socket 
(theSocketType, thePortNum) when ClientSocket or Serv- 
erSocket is created. A ServerSocketc class implements 
client type sockets under Unix using either TCP/IP or 
TCP/UDP. ServerSocketC is inherited by RMServerSocket 
when RMServerSocket is created. An InboxParser.c class 
used as a repository for the RM Metadata. The class' "build" 
member function reads the string which contains the data to 
store and the class parses the string it receives. After a 
message has been received, the MCIInboxParser object is 
created in inboxutl.c which is a file containing the functions 
which process the Inbox requests, i.e, Delete, List, Fetch and 
Update (Appendix G). Additional objects/classes include: 
Environ.c which provides access to a UNIX environment; 
Process.c which provides a mechanism to spawn slave 
processes in the UNIX environment; Daemon.c for enabling 
a process to become a daemon; Exceptions for exception 
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handling in C++ programs; and, RMlog.c for facilitating RM 
logging. In addition custom ESQL code for RM/database 
interface is provided which includes the ESQC C interface 
(Informix) stored procedures for performing the ARD, DRD, 
5 DUR, URS, GRD, CRD, and GPL messages. The functions 
call the stored procedures according to the message, and the 
response is build inside the functions depending on the 
returned values of the stored procedures. A mainsql.c pro- 
gram provides the ESQL C interface for messages from the 
report manager and report viewer. 

A list of Report Manager and Inbox proxy error messages 
can be found in Appendix E. 

Outgoing (server-to-client) communications follow the 
reverse route, i.e., the proxies will feed responses to the 
decode/dispatch server, which will encrypt the client-bound 
15 messages and communicate them to the DMZ Web servers 
over the socket connection. The Web servers will forward 
the information to the client using SSL. The logical message 
format returned to the client from the middle tier service is 
shown as follows: 

20 



H TCP/TP || encryption || http || web 'response || 
dispatcher response || proxy-specific response [| 



where || separates a logical protocol level, and protocols 
nested from left to right. 

The foregoing merely illustrates the principles of the 
present invention. Those skilled in the art will be able to 
3 q devise various modifications, which although not explicitly 
described or shown herein, embody the principles of the 
invention and are thus within its spirit and scope. 

What is claimed is: 

1. A Web/Intemet based reporting system for providing 
35 timely delivery of a customer's priced telecommunications 
call detail data to a client workstation running a web browser 
application, said system comprising: 
a data warehousing infrastructure comprising: 

process for generating a current customer list on a daily 
40 basis comprising customers entitled to receive daily 

telecommunications call detail data; 
device for receiving customer's raw telecommunica- 
tions call detail data records from one or more 
telecommunications network switch mechanisms, 
45 and extracting certain call detail records for prede- 

termined customers; 
harvest device for receiving said extracted call detail 
data records and replacing a call detail data item 
therein with a corresponding dimension key found in 
50 an associated dimension build table for that call 

detail item; and, 
device for generating an output fact table comprising 
customer records having unique key structures for 
enabling consolidated storage of specific customer 
55 call detail data; 

at least one secure server for managing client sessions 
over the Internet, the secure server supporting secure 
communication of customer request messages between 
the browser application client and the secure server; 
60 and, 

device for receiving said customer requests from said 
secure server and generating corresponding database 
queries implementing said dimension keys for applica- 
tion against said output fact table to obtain a specific 
65 call customer's call detail data, said call detail data 
being transmitted back to said client web browser via 
said secure server; 
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whereby expedient and updated web/Internet-based 
access to said customer's daily call detail data is 
assured. 

2. The system as claimed in claim 1, wherein said 
dimension build tables are continuously generated and 
updated with key structures for each extracted telecommu- 
nications call detail data record having a call detail item in 
which no associating match is found. 

3. The system as claimed in claim 1, wherein said harvest 
device applies look-ups to each of said one or more dimen- 
sion build tables having said unique dimension keys, said 
harvest device further replacing a call detail data item 
therein with a corresponding key structure when a match is 
found. 

4. The system as claimed in claim 2, wherein a dimension 
table includes a dimension key associated with a particular 
billing/customer, said system further comprising process for 
updating said billing/customer dimension table prior to 
inputting a received modified call detail record to said 
harvest device. 

5. The system as claimed in claim 3, wherein said 
updating of said billing/customer dimension includes pro- 
cess for comparing said current customer list with a cus- 
tomer list from a prior point in time, wherein new customers 
in said current daily list is added to said billing/customer 
dimension build table. 

6. The system as claimed in claim 3, further including a 
device for organizing said fact table and dimension tables in 
one or more operational data storage devices, said opera- 
tional data storage devices comprising a database server for 
facilitating expedient retrieval of customer's daily call detail 
data upon received customer requests. 

7. The system as claimed in claim 3, further including a 
tranlation process for converting call detail data in said fact 
table from a first character format to a second character 
format, and transferring said fact table data to said opera- 
tional data storage devices via ftp protocol. 

8. The system as claimed in claim 1, wherein said output 
fact table and said dimension build tables are organized 
according to a star schema structure. 

9. The system as claimed in claim 2, wherein said 
dimension build tables include dimension keys associated 
with a particular calling area. 

10. The system as claimed in claim 5, further including 
dispatch server for communicating with said secure server 
through a firewall over a second socket connection, the first 
and second secure sockets forming a secure communications 
link, said dispatch server enabling forwarding of a report 
request message and an associated report response message 
comprising requested call detail data back to the client 
browser over the secure communications link. 

11. The system as claimed in claim 9, further including a 
report manager server for maintaining an inventory of priced 
call detail reporting items associated with a customer and 
managing the reporting of daily call-detail data information 
in accordance with a customer request message, the report 
manager initiating access to said customer daily call detail 
data from said operational data stores. 

12. The system as claimed in claim 5, wherein said data 
warehousing infrastructure further includes process for 
totaling each customer's daily call detail data for a prede- 
termined period of time. 

13. The system as claimed in claim 12, further including 
process for verifying data harvesting and database load 
totals. 

14. The system as claimed in claim 12, wherein said data 
warehousing infrastructure is further capable of providing 
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output fact table associated with customer's monthly call 
detail data that has been repriced, said system further 
including process for reconciling a customer's daily call 
detail data totals in said operational data storage device with 

5 that customer's repriced monthly call detail data. 

15. The system as claimed in claim 14, wherein said 
reconciling process includes process for fragmenting blocks 
of call detail data included in said operational data storage 
devices with repriced monthly call detail data. 

1Q 16. A method for providing timely delivery of a custom- 
er's priced telecommunications call detail data to a client 
workstation running a web browser application comprising 
the steps of: 

generating a current customer list on a daily basis com- 
prising customers entitled to receive daily telecommu- 
15 nications call detail data; 

receiving customer's daily raw telecommunications call 
detail data records from one or more telecommunica- 
tions network switch mechanisms, and extracting those 
call detail data records for only those customers entitled 

20 

to receive said call detail data; 

receiving said extracted call detail data records and 
replacing one or more call detail data items therein with 
a corresponding dimension key found in a dimension 
25 build table associated with said call detail item; and, 

generating an output fact table comprising customer 
records having said unique key structures for enabling 
consolidated storage of specific customer call detail 
data; 

30 implementing a secure server to manage client sessions 
over the Internet, the secure server supporting secure 
communication of customer request messages between 
the browser application client and the secure server; 
and, 

35 receiving said customer requests from said secure server 
and generating corresponding database queries imple- 
menting said dimension keys for application against 
said output fact table to obtain a specific customer's 
call detail data, said call detail data being transmitted 

40 back to said client web browser via said secure server, 
whereby expedient and updated web/lnternet-based 
access to said customer's daily call detail data is 
assured. 

17, The method as claimed in claim 16, wherein said step 

45 of replacing a call detail data item therein with a corre- 
sponding dimension key includes implementing a dimension 
table look-up of the call detail item for a key structure 
corresponding to said call detail item and replacing said key 
in said record when a match is found. 

50 18, The method as claimed in claim 17, wherein said step 
of replacing said call detail item with said corresponding 
dimension key further includes the step of generating a new 
key to replace said call detail item and providing said new 
key to said dimension build table when no match is found. 

55 19. The method as claimed in claim 18, wherein a 
dimension table includes a dimension key associated with a 
particular billing/customer, said method further updating 
said billing/customer dimension table prior to inputting a 
received modified call detail record to a harvest device. 

60 20. The method as claimed in claim 19, wherein said step 
of updating said billing/customer dimension includes com- 
paring said current daily customer list with a customer list 
from an immediate prior day, wherein new customers in said 
current daily list is added to said billing/customer dimension 

65 build table. 

21. The method as claimed in claim 20, wherein said 
output fact table is capable of being loaded into storage/ 
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retrieval devices, said method further including the step of 
organizing said fact table and dimension tables in one or 
more operational data storage devices, said operational data 
storage devices comprising a database server for retrieving 
customer's daily call detail data upon received customer 
requests. 

22. The method as claimed in claim 21, further including 
the step of converting call detail data in said fact table from 
a first character format to a second character format, and 
transferring said fact table data to said operational data 
storage devices via ftp protocol. 

23. The method as claimed in claim 21, wherein said fact 
table and dimension tables are organized according to a star 
schema structure. 

24. The method as claimed in claim 23, wherein a 
dimension table includes dimension keys associated with a 
particular calling location. 

25. The method as claimed in claim 24, further including 
the step of forwarding a report request message and an 
associated report response message containing requested 
call detail data back to the client browser over a secure 
communications link. 

26. The method as claimed in claim 25, further including 
maintaining an inventory of priced call detail reporting items 
associated with a customer and managing the reporting of 
daily call-detail data information in accordance with a 
customer request message, and initiating access to said 
customer daily call detail data stored in said operational data 
stores. 

27. The method as claimed in claim 26, further including 
the step of totaling one or more call detail data item values 
for a predetermined period of time. 

28. The method as claimed in claim 26, further providing 
an output fact table associated with customer's monthly call 
detail data that has been repriced, said method further 
including reconciling a customer's daily call detail item 
value totals in said operational data storage device with that 
customer's repriced monthly call detail data. 

29. The method as claimed in claim 28, wherein said 
reconciling step includes fragmenting blocks of call detail 
data included in said operational data storage devices with 
repriced monthly call detail data. 

30. The method as claimed in claim 26, further including 
interfacing with a report manager server for retrieving the 
customer-specific data from the operational data stores in 
accordance with a customer identity and report name. 

31. The method as claimed in claim 26, further including 
generating a report utilizing the retrieved data and the 
metadata description of call detail reporting items. 



,979 Bl 

54 

32. A Web/Internet based reporting system for providing 
timely delivery of a customer's priced telecommunications 
call detail data to a client workstation running a web browser 
application, said system comprising: 

a data warehousing infrastructure comprising: 

a traffic component to receive raw telecommunications 
call detail records from one or more telecommuni- 
cations switches and to sort the call detail records 
( into billing detail records; 

a billing system to perform pricing in connection with 

one or more billing detail records; 
an extraction component to extract selected customer 
billing detail records; 
, a harvesting component to transform the selected bill- 
ing detail records based on a set of business rules into 
transformed billing detail records; 
a data store component to store the transformed billing 
detail records into one or more data marts; 
, at least one secure server for managing client sessions 
over the Internet, the secure server supporting secure 
communication of customer requests between the 
browser application client and the secure server; and, 
a device for receiving the customer requests from the 
25 secure server and generating corresponding database 
queries to obtain a specific customer's call detail data, 
the call detail data being transmitted back to said client 
web browser via the secure server. 

33. The system of claim 32 wherein the traffic component 
30 comprises a module to convert the raw telecommunications 

call detail records into a format that is readable by a 
mainframe. 

34. The system of claim 32 wherein the traffic component 
comprises a module to determine if records are billable and 

35 drops unbillable records. 

35. The system of claim 32 wherein the extraction com- 
ponent comprises a file transfer protocol pull of a list of 
selected customers. 

36. The system of claim 32 wherein the set of business 
40 rules for transforming the selected customer billing detail 

records comprises a star schema data model which incor- 
porates a central fact table and a plurality of referenced 
dimension tables. 

37. The system of claim 32 wherein the data warehousing 
45 infrastructure comprises a component to provide 

incremental, daily updates to the transformed billing detail 
records stored in the one or more data marts. 

* * * + * 
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